შესრულება და მაჩვენებლები

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 commit latency ქვემოთ L, რიგები სტაბილურია 50%-ზე ნაკლები სიმძლავრის და ნახვა ცვლილებები იშვიათია	ოპერაცია მუშაობს, მაგრამ შეზღუდული ტოლერანტობაა.
დაბალი	მიღებული გამტარობა არის Y ქვემოთ, p95 commit latency აღემატება L, რიგები იზრდება მიმდინარეობის დროს ან ხედვის ცვლილების / უკანა ზეწოლის მაჩვენებლების მუდმივად ზრდის	მოთხოვნილი სამუშაო დატვირთვა აღემატება მინიმუმ ერთ ღილაკს

ძირითადი წესი არის რიგის მიმართულება. თუ წარდგენილი TPS უფრო დიდია, ვიდრე დაპირებული TPS და რიგის ზრდა გრძელდება, განთავსება გადატვირთულია მაშინაც კი, თუ მოკლე ნიმუშები ჯანსაღი გამოიყურება.

ნოდების რაოდენობა და კვორუმი

უფრო მეტი ვალიდატორი აუმჯობესებს ხარვეზების ტოლერანტობას, მაგრამ ზრდის კოორდინაციის, ხელმოწერისა და ქსელის შექმნის ხარჯებს. მიმდინარე Sumeragi დანერგვისას:

• დამტკიცებლის რიცხვი n გამოყოფს ხარვეზის ბიუჯეტს f = floor((n - 1) / 3)
• n >= 4 - საკომისიო კვორუმი არის 2f + 1
• n <= 3 -ისთვის ყველა ვალიდატორი აუცილებელია ვალდებულების მისაღებად
• დამკვირვებელი თანატოლები სინქრონიზაციის ბლოკებს, მაგრამ არ კენჭისყრა, წარდგენა ან შეკრება

ვალიდატორები	ხარვეზური ბიუჯეტი	შეასრულეთ კვორუმი.	შესაძლებლობების ცნობა
1 დან 3	0 პრაქტიკული offline slack	ყველა დამტკიცებელი	სასარგებლო განვითარებისა და მცირე ტესტებისათვის. ნებისმიერი დაკარგული ვალიდატორი შეიძლება შეაჩეროს კომისიები
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 .

უფრო დაბალი დროის მიზნები შეიძლება გააუმჯობესოს ლეტენცია მხოლოდ მაშინ, როდესაც ქსელის, შენახვისა და შესრულების ფენებს შეუძლიათ თანმიმდევრობა. მას შემდეგ, რაც ცვლილებების ნახვა, დაკარგული სასარგებლო ტვირთის მოძიება ან უკანა ზეწოლა გამოჩნდება, დროის შემცირება ჩვეულებრივ უარყოფს შესრულებას.

კოლექტორი Fanout

კოლექტორის პარამეტრები გავლენას ახდენს იმაზე, თუ რამდენად სწრაფად შედიან კომიტეტის ხმები:

• sumeragi.collectors.k აკონტროლებს, თუ რამდენი კოლექტორი აგროვებს ხმებს სიმაღლის მიხედვით.
• sumeragi.collectors.redundant_send_r კონტროლებს დამატებით ხმის მიცემას ადგილობრივი დროის შემდეგ
• sumeragi.collectors.parallel_topology_fanout დამატება topology fanout ერთად კოლექტორები

გაზრდილი ფანოუთი შეიძლება შეამციროს ტაილ ლატენცია უფრო დიდ ან ნაკლებად საიმედო ქსელებში, მაგრამ ის ასევე ზრდის მოძრაობას. შეადარეთ აგრეგირებული ხელმისაწვდომობა და კოლექტორის ტელემეტრია ლატენციისა და უკანა ზეწოლის მაჩვენებლებთან სანამ შეცვლით ამ მნიშვნელობებს:

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

ქსელის პირობები

კონსენსუსის შედეგები მგრძნობიარეა:

• RTT ვალიდატორებს შორის
• შეშფოთება და პაკეტის დაკარგვა
• ბლოკის სასარგებლო ტვირთებისა და RBC ნაჭრების ზღვრის სიგანე;
• რეგიონებს შორის ასიმეტრიული კავშირები
• NAT, firewall ან რელიე ქცევა, რომელიც შეფერხებს თანატოლების კავშირს

დაგეგმვის წესად, დააყენეთ ლეტენციის ბიუჯეტი საკმარისად მაღალ დონეზე, რათა დაფაროს რამდენიმე ვალიდატორის ბრუნვა-გასვლა და შესრულება და დისკის ჩართვის დრო. თუ p95 ქსელი RTT უკვე ახლოსაა სასურველი p95 ჩართვის ლეტენციასთან, მიზანი არ არის რეალური.

რიგები და შესვლის შეზღუდვები

შეყვანის და რიგის პარამეტრები განსაზღვრავს, თუ რა რაოდენობის დარტყმების წნეხი შეიძლება შეიწოვოს თანასწორმა:

• queue.capacity
• queue.capacity_per_user
• queue.transaction_time_to_live_ms
• გენეზიის ტრანზაქციის ლიმიტები, როგორიცაა მაქსიმალური ხელმოწერები, ინსტრუქციები, ბაიტები და დეკომპრესირებული ბაიტები
• p2p რიგის საზღვრები და კონსენსუსული შესვლის ლიმიტები

მაღალი რიგის სიმძლავრე შეიძლება მალოს გადატვირთვა გარკვეული პერიოდის განმავლობაში, მაგრამ ეს არ ზრდის მდგრად გამტარებას. სტაბილური რიგის ჯანმრთელობაა; მზარდი რიგის მიღმა დარჩენა არის ჩამორჩენილი.

ტექნიკა და შენახვა

გაზომეთ ყველა დამტკიცებელი, და არა მხოლოდ ლიდერი:

• CPU გაჯერება ვალიდაციის, ხელმოწერის შემოწმების და შესრულების დროს
• მეხსიერების წნეხი რიგებიდან, სურათებიდან და აქტიური RBC სესიებიდან.
• დისკის დაწერის ლატენცია ბლოკების შენახვისა და გადაღებებისათვის
• ქსელის გადაცემა/მიღება saturation
• სამუშაო დატვირთვით გამოყენებისას საბაჟო აჩქარების ფორმატირება

ყველაზე ნელი კენჭისყრის ვალიდატორს შეუძლია განსაზღვროს ქსელის ზურგის ლატენცია.

პრომეტეუსის სიგნალები

მეტრიკის სახელები შეიძლება განსხვავდებოდეს შექმნის პროფილის და მახასიათებლების კომპლექტის მიხედვით. ჯერ შეამოწმეთ /metrics თქვენი კვანძზე, შემდეგ კი შექმენით დეშბორდები ხელმისაწვდომი სერიების გარშემო.

საერთო სიგნალები მოიცავს:

სიგნალი	Prometheus-ის მაგალითები	რა უნდა ვუყუროთ?
მიღებული გამტარობა	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 scrape.

შეფასება სამუშაო მიმდინარეობა

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, ზედმეტი გამოგზავნა r და ტოპოლოგიური ფანოუტი
• ტელემეტრიის პროფილი
• აღჭურვილობის, შენახვის და OS დეტალები
• ქსელის RTT, jitter, დანაკლისი და ზღვრის სიგანის ვარაუდები
• ტრანზაქციების შერეული და სასარგებლო ტვირთის ზომები
• შემოთავაზებული TPS და მიმდინარეობის ხანგრძლივობა
• მიღებული/გარიცხული TPS
• p50/p95/p99 კომიტეტის ლატენცია
• რიგის სიღრმე და სიმკვრივე
• განხილვა ცვლილებები, შეტყობინებები, RBC წნეხი და დაკარგული სასარგებლო ტვირთის მაჩვენებლები
• CPU, მეხსიერება, დისკი და ქსელის გამოყენება თითოეული ვალდიტორის მიხედვით

ამ დეტალების გარეშე, TPS ნომერი უნდა ჩაითვალოს ანეკდოტურად.

დაკავშირებული გვერდები

• ქაოსის ტესტირება Izanami-სთან
• Torii საბოლოო წერტილები
• ოპერირება Iroha 3 მეშვეობით CLI
• პარტნიორი კონფიგურაციის რეფერენცია