Արդյունավետություն եւ չափանիշներ

Iroha կատարումը կախված է աշխատանքային բեռնվածությունից, վավերացողի տոպոլոգիայից, ցանցի պայմաններից եւ կոնսենսուսային կարգավորումներից: Հետեւաբար, մեկ TPS թիվը օգտակար է միայն այն դեպքում, երբ կապվում է ֆիքսված կոֆիգուրացիայի հետ ստանդարտ ցուցանիշի գործարկման հետ:

Հզորության պլանավորման համար կատարողականը դիտարկել որպես շահագործման առումով.

• ցանցը ընդունում է պահանջված գործարքի տոկոսադրույքը
• պարտավորեցնել հետաձգման ժամանակահատվածի մնալը նպատակային բյուջեի մեջ
• գործարքային հերթերը սահմանափակվում են
• կոնսենսուսը չի հիմնվում կրկնվող դիտման փոփոխությունների կամ վերականգնման ուղիների վրա:

Օգտագործեք այս էջը ՝ գնահատելու համար, թե արդյոք տեղակայումը բարձր, միջին կամ ցածր կատարողական վիճակում է տվյալ բջիջների քանակության, ցանցի լատենցիայի շեմի եւ նպատակային TPS համար:

Ինչ պետք է չափել

Սկսեք Torii կողմից բացված օպերատորի մակերեւույթներից:

export TORII=http://127.0.0.1:8180

curl -s "$TORII/status" | jq .
curl -s -H 'Accept: application/json' "$TORII/v1/sumeragi/status" | jq .
curl -s "$TORII/v1/sumeragi/phases" | jq .
curl -s "$TORII/v1/sumeragi/rbc" | jq .
curl -s "$TORII/v1/sumeragi/params" | jq .
curl -s "$TORII/metrics" > metrics.prom

Դուք կարող եք փորձել նույն ընթերցման միայն ձեւը հանրային Taira:

TAIRA=https://taira.sora.org

curl -fsS "$TAIRA/status" \
  | jq '{blocks, txs_approved, txs_rejected, queue_size, peers}'

curl -fsS "$TAIRA/v1/time/status" \
  | jq '{healthy: .health.healthy, peers, samples_used, rtt_count: .rtt.count}'

curl -fsS "$TAIRA/metrics" \
  | grep -E '^(block_height|queue_size|sumeragi_tx_queue_depth|txs|view_changes)' \
  | head -n 20

Հասարակական Taira չափանիշները օգտակար են ազդանշանների անվանումները սովորելու համար: Մի օգտագործեք դրանք որպես արտադրողական հզորության թվեր ձեր սեփական տեղակայման համար:

Նույն կոնսենսուսային լուսանկարները հասանելի են CLI միջոցով.

iroha --config ./localnet/client.toml --output-format text ops sumeragi status
iroha --config ./localnet/client.toml --output-format text ops sumeragi phases
iroha --config ./localnet/client.toml --output-format text ops sumeragi telemetry
iroha --config ./localnet/client.toml ops sumeragi params

Հեռաչափության տեսանելիությունը կախված է կոնֆիգուրացված պրոֆիլից: Օգտագործեք extended, երբ ձեզ անհրաժեշտ է /metrics, եւ օգտագործեք full փորձարկման ընթացքում, երբ նաեւ պետք է մանրամասն Sumeragi օպերատոր երթուղիներ.

telemetry_enabled = true
telemetry_profile = "full"

Պերֆորմացիայի ժապավեններ

Օգտագործեք այս տերեւները դիտարկված երթեւեկության համար թիրախային անցում Y TPS եւ ուշացման բյուջետ L միլիսիկունտներում: Շարունակեք աշխատանքային բեռը բավականաչափ երկար, որպեսզի ներառեք ջերմացում, կայուն վիճակ եւ առնվազն մեկ ժամանակահատված ակնկալվող առավելագույն բեռնվածությունը:

Գավաթ	Պայմաններ	Նշում
Բարձր	Ընդունված ներթափանցումը հասնում է կամ գերազանցում Y, p95 հանձնարարականի հետաձգման ժամկետը ցածր է 0.8 * L, հերթերը մնում են հզորության 10%-ից ցածր, եւ տեսանկյունի փոփոխություն/վերականգնման հաշվիչները հարթ են:	Բնակչության տեղակայման համար անհրաժեշտ աշխատանքային բեռնվածություն է:
միջին	Ընդունված ներուժը մոտ է Y, p95 հանձնարարականի հետաձգումը ցածր է L, հերթերը կայուն են 50%-ից ցածր եւ տեսողական փոփոխությունները հազվադեպ են լինում:	Գործարկումը գործում է, բայց պայթյունի հանդուրժողականությունը սահմանափակ է:
ցածր	Ընդունված թափանցիկությունը Y -ից ցածր է, p95 պարտավորության հետաձգումը գերազանցում է L-ը, երթեւեկության ընթացքում հերթերը աճում են կամ հեռանկարային փոփոխության/հակառակ ճնշման հաշվիչները շարունակաբար աճում են:	Աշխատանքի պահանջվող բեռը գերազանցում է առնվազն մեկ շշնջուղի խոչընդոտը

Գլխավոր կանոնն է հերթի ուղղությունը: Եթե ներկայացված TPS մեծ է, քան պարտավորվել է TPS եւ հերթը շարունակում է աճել, տեղակայումը գերբեռնված է նույնիսկ եթե կարճ նմուշները առողջ են թվում:

Նոթների թիվը եւ քվորումը

Ավելի շատ վավերացնողներ բարելավում են սխալների հանդուրժողականությունը, բայց ավելացնում են համակարգման, ստորագրության եւ ցանցի դուրս գալու ծախսերը: Ներկայիս Sumeragi իրականացման դեպքում

• վավերացնող հաշվարկը n ստացվում է սխալների բյուջեն f = floor((n - 1) / 3):
• n >= 4 համար հանձնաժողովի քվորումը կազմում է 2f + 1
• n <= 3 համար պարտավորության համար պահանջվում են բոլոր վավերացնողները
• դիտորդների զուգընկերները համաժամեցնում են բլոկերը, բայց չեն քվեարկում, առաջարկում կամ հավաքում

Փաստաբաններ	Սխալ բյուջե	Կատարեք քվորում:	Հասունակության ծանուցում
1-ից մինչեւ 3	0 գործնական օֆլեյն ազատություն	բոլոր վավերացողները	Օգտակար է մշակման եւ փոքր փորձարկումների համար: Ցանկացած բացակայող վավերացնողը կարող է հետաձգել պարտավորությունները
4	1	3	Միավոր սխալների հանդուրժողականության համար ընդհանուր նվազագույն
7	2	5	Ավելի դիմացկուն, ավելի շատ քվեարկության եւ տարածման երթեւեկությամբ
10	3	7	Կոորդինացիայի ավելի բարձր ծախսերը: Համացանցի եւ հավաքիչների հարմարեցումը ավելի կարեւոր է:

"X հանգույցները" գնահատելիս քվեարկության վավերացողները բաժանվում են դիտորդներից: դիտորդների ավելացումը սովորաբար ավելի ցածր է ծախսում, քան հաստատիչների ավելացումը, բայց դիտորդները դեռ սպառում են բլոկ գովազդներ, բլոկ սինկորացիա, սկավառակ եւ ցանցային թողունակություն:

Տարբեր գործոններ, որոնք ազդում են կատարման վրա

Աշխատանքային բեռի ձեւը

Նույն TPS կարող է լինել ցածր կամ թանկ, կախված այն բանից, թե ինչ է կատարվում յուրաքանչյուր գործարքի հետ:

• յուրաքանչյուր գործարքի վերաբերյալ հրահանգների թիվը
• ստորագրության հաշման եւ ստորագրման ալգորիթմները
• գործարքի բայթերի չափը եւ դեկոմպրեսացված օգտակար լիցքավորման չափը
• ընթերցման/գրելու հարաբերակցությունը
• Մետադատային տվյալների չափը եւ ակտիվների գործողությունները
• խելացի պայմանագիր, գործարկիչ եւ կատարման ծախսեր IVM
• հարցման ծանրաբեռնվածությունը նույն զուգընկերների դեմ

Փոքր տրանսֆերային գործարքները պայմանագրերով ծանր կամ մետադատա ծանր աշխատանքային բեռնվածքների փոխարինող չեն:

Համաձայնության ժամկետը

Sumeragi ժամկետը վերահսկվում է Sumeragi արդյունավետ պարամետրերի միջոցով.

• block_time_ms
• commit_time_ms
• min_finality_ms
• pacing_factor_bps
• NPoS փուլային ժամանակահատվածներ, երբ NPoS ռեժիմը ակտիվ է:

Նրանց ստուգեք հետեւյալ կերպ.

iroha --config ./localnet/client.toml ops sumeragi params
curl -s "$TORII/v1/sumeragi/params" | jq .

Ավելի ցածր ժամանակավորության նպատակները կարող են բարելավել ուշացումը միայն այն ժամանակ, երբ ցանցի, պահեստավորման եւ կատարման շերտերը կարող են հետեւել: Երբ փոփոխությունները դիտվում են, բացակայում է շահագործման բեռնվածություն կամ հետագա ճնշում հայտնվում է, ժամանակավորների նվազեցումը սովորաբար վատթարացնում է կատարողականը.

Հավաքիչ Ֆանոուտ

Հավաքիչի կարգավորումները ազդում են այն բանի վրա, թե որքան արագ են համախմբվում հանձնաժողովների քվեները.

• sumeragi.collectors.k վերահսկում է, թե որքան հավաքողներ են հավաքում քվեները բարձրության համար
• sumeragi.collectors.redundant_send_r վերահսկում է լրացուցիչ քվեարկությունը տեղական ժամանակահատվածից հետո
• sumeragi.collectors.parallel_topology_fanout ավելացնում է topology fanout հավաքիչների հետ միասին

Fanout- ի ավելացումը կարող է նվազեցնել մեծ կամ ավելի քիչ հուսալի ցանցերում տագնապային լատենտությունը, բայց այն նաեւ ավելացնում է երթեւեկությունը: Համեմատեք ընդհանուր հասանելիությունն ու հավաքիչի հեռաչափը լատենտի եւ հետընտրական ճնշման չափանիշների հետ նախքան այս արժեքները փոխելը.

iroha --config ./localnet/client.toml --output-format text ops sumeragi telemetry

Համացանցի պայմանները

Համաձայնության կատարումը զգայուն է հետեւյալը.

• RTT վավերացնողների միջեւ
• զյարդայնություն եւ փաթեթի կորուստ
• բլոկային օգտակար ծանրաբեռնվածքների եւ RBC մասերի համար թողունակության լայնությունը
• տարածաշրջանների միջեւ անհամաչափ կապեր
• NAT, կրակի պատ, կամ ռեալի վարքագիծ, որը հետաձգում է զուգընկերների կապը

Որպես պլանավորման կանոն, սահմանեք լատենցիայի բյուջեն բավականաչափ բարձր, որպեսզի կարողանա ընդգրկել մի քանի վավերացողի շրջադարձային ուղեւորություններ, գումարած կատարման եւ սկավառակի պարտավորությունների ժամանակ: Եթե p95 ցանցը RTT արդեն մոտ է ցանկալի p95 պարտավորությունների հետաձգմանը, նպատակն իրական չէ:

Թերթեր եւ մուտքի սահմանափակումներ

Թողարկման եւ հերթի կարգավորումները սահմանում են, թե որքան պայթյունային ճնշում կարող է ընկալել զուգընկեր:

• queue.capacity
• queue.capacity_per_user
• queue.transaction_time_to_live_ms
• genesis գործարքի սահմանները, ինչպիսիք են առավելագույն ստորագրությունները, հրահանգները, բայթերը եւ կոմպրեսացված բայթները
• p2p հերթի ծայրերը եւ կոնսենսուսային մուտքի սահմանները

Բարձր հերթի հզորությունը կարող է մի ժամանակով թաքցնել գերբեռնվածությունը, բայց դա չի մեծացնում կայուն արտադրանքը: Կայուն հերթը առողջ է; աճող հերթը հետապնդում է:

Հարդքորներ եւ պահեստավորում

Քննեք յուրաքանչյուր վավերացնող, ոչ միայն առաջնորդը.

• CPU վավերացման, ստորագրության ստուգման եւ կատարման ընթացքում լցվածությունը
• հիշողության ճնշումը հերթերի, լուսանկարների եւ ակտիվ RBC նստաշրջաններից:
• բլոկային պահեստավորման եւ լուսանկարի համար սկավառակի գրման ուշացում
• ցանցի փոխանցման/ընդունման լցվածությունը
• աշխատանքային ծանրաբեռնվածության ժամանակ գործնական սարքավորումների արագացման ընտրանքային կարգավորումները

Քվեարկության ամենադանդաղ վավերացնողը կարող է որոշել ցանցի հետագա ուշացումը:

Պրոմետեոսի ազդանշանները

Մետրիկ անունները կարող են տարբերվել կառուցել պրոֆիլ եւ առանձնահատկությունների հավաքածու. Նախ ստուգեք /metrics ձեր հանգույցի վրա, այնուհետեւ ստեղծեք վահանակային սեղաններ ՝ հասանելի շարքի շուրջ:

Սովորական ազդանշանները ներառում են.

Սիմգալ	Պրոմետեուսի օրինակներ	Ի՞նչ դիտել:
Ընդունված արտահոսք	sum(rate(txs{type="accepted"}[5m]))	Կպահպանել կամ գերազանցել նպատակային TPS մակարդակը:
Հրաժարականներ	sum(rate(txs{type="rejected"}[5m]))	Հարկ է բացատրել փորձաքննության պլանը:
Պատվիրել ուշացում	histogram_quantile(0.95, sum(rate(commit_time_ms_bucket[5m])) by (le))	Համեմատեք p95/p99-ը հետաձգման բյուջեի հետ
Էջի խորությունը	queue_size, sumeragi_tx_queue_depth	Պետք է պահպանել սահմանը բեռնման բարձրության ժամանակ:
Էջի հագեցածություն	sumeragi_tx_queue_saturated	Պահպանվող ոչ զրոյական արժեքները միջին գերբեռնվածություն
Նայեք փոփոխությունները	view_changes, sumeragi_view_change_suggest_total, sumeragi_view_change_install_total	Բարձրացվող արժեքները ցույց են տալիս ժամանակի, տոպոլոգիայի, օգտակար բեռնվածության կամ ցանցի խնդիրների
Թողված հաղորդագրություններ	dropped_messages, sumeragi_consensus_message_handling_total	Լիցքավորման ընթացքում նվազումները սովորաբար բացատրում են լատենցիայի բարձրացումը
RBC ճնշում	sumeragi_rbc_store_pressure, sumeragi_rbc_backpressure_deferrals_total	Ոչ զրոյական ճնշման կետեր 'օգտագործելի բեռի վերականգնման կամ պահեստավորման շշնջեղների համար:
Կատարեք քվորում:	sumeragi_commit_signatures_counted, sumeragi_commit_signatures_required	Հաշվարկված ստորագրությունները պետք է արագ հասնեն պահանջվող քվորումին:

Երբ մետրիկան գոյություն ունի միայն /v1/sumeragi/status, նկարագրեք JSON ակնթարթային լուսանկարը Prometheus- ի խեղդման նույն ընթացքի արվեստի գործիքների մեջ:

Գործընթացների գնահատականներ

1. Պարզեք սցենարը.

   • վավերացնողների եւ դիտորդների թիվը
   • կոնսենսուսի ռեժիմ
   • նպատակային TPS
   • p95 եւ p99 պարտավորությունների հետաձգման բյուջեները
   • գործարքային խառնուրդ
   • սպասվող ցանց RTT, jitter եւ թողունակություն

2. Գրիր արդյունավետ կարգավորումը.

   iroha --config ./localnet/client.toml --output-format json ops sumeragi params \
     > artifacts/sumeragi-params.json
   curl -s "$TORII/v1/sumeragi/collectors" \
     > artifacts/sumeragi-collectors.json

3. Աշխատանքային ծանրաբեռնվածությունը գործարկեք թիրախի վրա TPS։

4. Գտեք ընթացքի սկզբում, միջին եւ վերջում ստացված վիճակը եւ չափանիշները:

5. Գործընթացը դասակարգեք կատարողական տերեւի սեղանի միջոցով:

6. Եթե ժապավենը միջին կամ ցածր է, միաժամանակ փոխեք մեկ գործոն եւ կրկնեք:

Համացանցային զեկույցի ձեւանմուշ

Հրապարակել կատարողական թվերը միայն բավարար համատեքստով, որպեսզի դրանք վերարտադրվեն.

• Iroha պարտավորության, ազատման եւ առանձնահատկությունների դրոշներ
• վավերացողի եւ դիտորդի հաշվարկը
• Համաձայնության ռեժիմ եւ Sumeragi պարամետրեր
• հավաքիչ k, redundant ուղարկել r, եւ topology fanout
• հեռաչափության պրոֆիլ
• Hardware, պահեստավորման եւ OS մանրամասներ
• ցանց RTT, jitter, կորուստ եւ թողունակության ենթադրությունները
• գործարքի խառնուրդը եւ շահագործման բեռի չափերը
• առաջարկված TPS եւ ընթացքի տեւողությունը
• ընդունված / մերժված TPS
• p50/p95/p99 հանձնարարականի հետաձգում
• հերթի խորությունը եւ լցվածությունը
• դիտարկում փոփոխություններ, բաց թողնված հաղորդագրությունները, RBC ճնշումը եւ բացակայող շահագործման ծանրաբեռնվածության հաշվիչները
• CPU, հիշողություն, սկավառակ եւ ցանցի օգտագործումը մեկ վավերացողի համար

Առանց այդ մանրամասների, TPS թիվը պետք է դիտարկվի որպես անեկդոտիկ:

Կապակցված էջեր

• Ցավալի փորձարկումներ Izanami- ի հետ
• Torii վերջնական կետեր
• Գործարկել Iroha 3 միջոցով CLI:
• Պերային կոնֆիգուրացիայի հղում