ביצועים ומטריקות

ביצועים 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 או מעל [PH000000, איחור הקבלה של p95 נמצא מתחת ל- 0.8 * L, השורות נשארות מתחת ל-10% מהקapacity, ומספרים לשינוי תצוגה/התאוששות הם שטובים	המשלוח יש מקום למשאב העבודה הנדרש
בינוני	ההפעלה המקובלת קרובה ל Y, העומס של p95 הוא מתחת ל L, השורות יציבות מתחת 50% מהקapacity, ושינויים בתצוגה נדירים	השיגור עובד, אבל יש סבולת פיצוץ מוגבלת
נמוך.	המעבר המקובל הוא מתחת Y, העומס של p95 עולה על L, הזדרות גדלות במהלך ההפעלה, או מתפריטים לשינוי תצפית/לחץ לאחור גדלים ללא הרף	עומס העבודה הנדרש עולה לפחות על קווץ אחד

החוק המרכזי הוא כיוון השורה. אם הוצא TPS גדול יותר מההתחייב TPS והשורה ממשיכה לצמוח, ההתפעלת עומדת יתר על מידה גם אם דגימות קצרות נראות בריאותיות.

סכום הערך והקואורום

יותר מתבטיחים משפרים את סובלנות הטעות אך מגדילים את הוצאות הקואורדינציה, החתימה ותוצאת הרשת. בהיישמת הנוכחית Sumeragi:

• סכום האישור n מביא את התקציב של הפגם f = floor((n - 1) / 3)
• עבור n >= 4, קוורום מחויבות הוא 2f + 1
• עבור n <= 3, כל המבטיחים נדרשים לקבוע
• עמיתים מתבוננים בבלוקים אבל לא מצביעים, מציעים או אוספים

מעודדים	תקציב טעויות	הקבע קוורום	הערה על היכולת
1 עד 3	תופעה לא מקוונת מעשית	כל המאושרים	שימושי עבור פיתוח וניסויים קטנים; כל מעודד חסר יכול לעכב מחויבויות
4	1	3	מינימום משותף לטיפול בתאונות אחת
7	2	5	עמידות רבה יותר, עם יותר תנועה להצביע והתרחבות
10	3	7	העלות הגבוהה יותר של שיתוף פעולה; חיזוק רשת וקטר חשוב יותר

בעת הערכת "נקודות ה-X", נפרדים מבקרי ההצבעה מהמתבוננים. הוספת מתבוננים בדרך כלל עולה פחות מאשר הוספת בדיקרים, אך המתבוננים עדיין צורכים בדיחות בלוק, סינכרון בלוק, דיסק ורוחב קו הרשת.

גורמים שמשפיעים על ביצועים

צורה של עומס עבודה

אותו TPS יכול להיות זול או יקר בהתאם למה שעושה כל עסקאות.

• מספר ההוראות על העסקה
• מספר חתימות ואלגוריתמים לחתום
• גודל בייט העסקה וגודל המטען הפועל המפוצץ
• יחס קריאה / כתיבה
• גודל הנתונים המטאטאליים ופעילות נכסים
• חוזה אינטליגנטי, תניע ועלות ביצוע IVM
• עומס חיפוש פועל נגד אותם עמיתים

עסקאות העברה קטנות אינן מעצבות עבור עומסי עבודה כבדים של חוזים או metadata.

זמן ההסכמה

זמן 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 מוסיף את הטופולוגיה לצד אספנים.

הגדילה של התצוגה יכולה להפחית את איטיות הזנב ברשתות גדולות או פחות אמינות, אך היא גם מגדלת את התנועה. השווא את זמינות הכוללת וטלמטריה הקולקטור עם מדרי האיטיות והלחץ האחורי לפני שינוי הערכים אלה:

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
• גבולות העסקה של הגנזה, כגון חתימות מקסימליות, הוראות, בייטים ובייטים מפורצים.
• גבולות קווים 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, ג'יטר, ורוחב הקו

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, ו-topology fanout
• פרופיל טלמטריה
• פרטים על חומרה, אחסון ו OS
• רשת RTT, הנחות של ג'יטר, אובדן ורחב הקו
• מישן העסקאות וגודל המשאבים הפועלים
• הוצעה TPS ותקופה של הריצה
• מקובל/מסרב TPS
• עיתוי קבלן p50/p95/p99
• עומק השורה ומלאה
• תצוגה של שינויים, הודעות נפטרות, לחץ RBC ומספרים של עומס חיוב חסר
• CPU, זיכרון, דיסק ושימוש ברשת על מסמך

ללא פרטים אלה, המספר TPS צריך להיות נחשב לאנקדוט.

דפים קשורים

• בדיקות כאוס עם Izanami
• נקודות קצה Torii
• פעל Iroha 3 באמצעות CLI
• דוגמה להגדרת עמיתים