کارکردگی اور پیمائش

Iroha کارکردگی ورک لوڈ ، توثیق کنندہ ٹاپولوجی ، نیٹ ورک کے حالات اور اتفاق رائے کی ترتیبات پر منحصر ہے۔ لہذا ایک واحد TPS نمبر صرف اس وقت مفید ہے جب یہ فکسڈ ترتیب والے بینچ مارک رن سے منسلک ہوتا ہے۔

صلاحیتوں کی منصوبہ بندی کے لئے، کارکردگی کو ایک آپریٹنگ لفافہ کے طور پر علاج کریں:

• نیٹ ورک درخواست کردہ ٹرانزیکشن ریٹ کو قبول کرتا ہے
• ہدف کے بجٹ کے اندر تاخیر کے قیام کا وعدہ کریں
• لین دین کی قطاریں محدود رہیں
• اتفاق رائے بار بار دیکھنے کی تبدیلیوں یا بازیابی کے راستوں پر انحصار نہیں کرتا ہے

اس صفحے کا استعمال یہ اندازہ کرنے کے لئے کریں کہ آیا ایک تعیناتی کسی دیئے گئے نوڈ گنتی ، نیٹ ورک کی تاخیر کی حد اور ہدف TPS کے ل a اعلی ، درمیانے یا کم کارکردگی کی حالت میں ہے۔

کیا ناپنا ہے

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

ٹیلی میٹری کی نمائش ترتیب شدہ پروفائل پر منحصر ہے۔ جب آپ کو /metrics کی ضرورت ہو تو extended کا استعمال کریں ، اور ٹیسٹ رن کے دوران full کا استعمال کریں جب آپ کو تفصیلی Sumeragi آپریٹر راستوں کی بھی ضرورت ہو۔

telemetry_enabled = true
telemetry_profile = "full"

کارکردگی کے بینڈ

ان بینڈوں کا استعمال ہدف ٹرانسپوٹ Y TPS اور تاخیر بجٹ L ملی سیکنڈ پر مشاہدہ شدہ رن کے لئے کریں۔ کام کی بوجھ کو گرم کرنے ، مستحکم حالت اور متوقع چوٹی لوڈ کے کم از کم ایک عرصے تک شامل کرنے کے ل running کافی لمبا چلائیں۔

بینڈ	حالات	معنی
اعلی	قبول شدہ ٹرانسمیٹ Y یا اس سے اوپر ہے، p95 کمیٹ لیٹینسی 0.8 * L سے نیچے ہے، قطاریں صلاحیت کے 10٪ سے کم رہتی ہیں، اور نقطہ نظر کی تبدیلی / بازیابی کاؤنٹر فلیٹ ہیں	اس تعیناتی میں مطلوبہ کام کے بوجھ کے لیے گنجائش ہے۔
میڈیم	قبول شدہ ٹرانسمیٹ Y کے قریب ہے، p95 کمیٹ لیٹینسی 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 عملی آف لائن لاک	تمام تصدیق کنندہ	ترقی اور چھوٹے ٹیسٹ کے لئے مفید؛ کسی بھی لاپتہ تصدیق کنندہ commits روک سکتا ہے
4	1	3	ایک غلطی کی برداشت کے لئے کم سے کم مشترکہ
7	2	5	زیادہ لچکدار، زیادہ ووٹ اور تبلیغاتی ٹریفک کے ساتھ
10	3	7	اعلی ہم آہنگی کی لاگت؛ نیٹ ورک اور کلکٹر ٹوننگ زیادہ اہم ہے

"ایکس نوڈس" کا اندازہ کرتے وقت ، ووٹنگ کی توثیق کرنے والوں کو مبصرین سے الگ کریں۔ مبصرین کو شامل کرنا عام طور پر توثیق کنندگان کو شامل کرنے سے کم لاگت آتی ہے ، لیکن مبصرین اب بھی بلاک گپ شپ ، بلاک ہم آہنگی ، ڈسک اور نیٹ ورک بینڈوتھ استعمال کرتے ہیں۔

کارکردگی پر اثر انداز کرنے والے عوامل

کام کے بوجھ کی شکل

ایک ہی 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 مجموعہ جات کے ساتھ ٹاپولوجی فانوٹ شامل کرتا ہے

بڑھتے ہوئے 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
• جنیسس ٹرانزیکشن کی حدیں جیسے زیادہ سے زیادہ دستخط ، ہدایات ، بائٹس اور ڈکامپریسڈ بائٹس
• پی 2 پی قطار کی حدیں اور اتفاق رائے میں داخل ہونے کی حدود

قطار کی اعلی صلاحیت تھوڑی دیر کے لئے اوورلوڈ کو چھپاسکتی ہے ، لیکن اس سے پائیدار آؤٹ پٹ میں اضافہ نہیں ہوتا ہے۔ ایک مستحکم قطار صحت مند ہے؛ بڑھتی ہوئی قطار ایک پیچھے رہتی ہے۔

ہارڈ ویئر اور اسٹوریج

ہر تصدیق کنندہ کی پیمائش کریں، نہ صرف لیڈر:

• CPU توثیق، دستخط کی تصدیق اور عملدرآمد کے دوران saturation
• صفوں، سنیپ شاٹس اور فعال RBC سیشن سے میموری پریشر۔
• بلاک اسٹوریج اور اسنیپ شاٹس کے لئے ڈسک لکھنے کی تاخیر
• نیٹ ورک ٹرانسمیشن / وصول saturation
• جب کام کے بوجھ میں استعمال کیا جاتا ہے تو اختیاری ہارڈ ویئر کی رفتار کی ترتیبات

سب سے سست ووٹنگ کی توثیق کنندہ نیٹ ورک کے دم تاخیر کا تعین کر سکتا ہے۔

Prometeus سگنل

میٹرکس کے نام تعمیر پروفائل اور خصوصیت سیٹ کے مطابق مختلف ہوسکتے ہیں۔ پہلے اپنے نوڈ پر /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 اسنیپ شاٹ کو پرومیٹیئس سکریپ کے طور پر اسی رن آرٹیفیکٹس میں قبضہ کریں.

اندازہ کاری ورک فلو

1. منظرنامے کی وضاحت کریں:

   • تصدیق کنندہ اور مبصرین کی تعداد
   • اتفاق رائے کا موڈ
   • ہدف TPS
   • p95 اور p99 commit-latency بجٹ
   • ٹرانزیکشن مکس
   • متوقع نیٹ ورک 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، اور ٹاپولوجی fanout
• ٹیلی میٹری پروفائل
• ہارڈویئر، اسٹوریج اور OS کی تفصیلات
• نیٹ ورک RTT، jitter، نقصان، اور بینڈوڈتھ مفروضے
• ٹرانزیکشن مکس اور مفید بوجھ کے سائز
• پیش کردہ TPS اور چلانے کی مدت
• قبول / مسترد TPS
• p50/p95/p99 commit latency
• قطار کی گہرائی اور تناؤ
• تبدیلیاں دیکھیں، پیغامات چھوڑ دیں، RBC دباؤ، اور لاپتہ مفید بوجھ کاؤنٹرز
• CPU ، میموری، ڈسک اور نیٹ ورک کا استعمال فی ویلیڈیٹر

ان تفصیلات کے بغیر، TPS نمبر کو غیر معمولی سمجھا جانا چاہئے.

متعلقہ صفحات

• Izanami کے ساتھ افراتفری ٹیسٹنگ
• Torii اختتام پوائنٹس
• Iroha 3 کے ذریعے CLI پر کام کریں
• پیئر ترتیب کا حوالہ