Kitsune2: חיפושים מהירים יותר ב251x, נתיב העדכון 33x, והדיסקוס התחיל ב15x מוקדם יותר
בתוך בוקר של ניסויים על שכבת הרשת של Holochain: איך צמתים מוצאים עמיתים, משיגים נתונים חסרים, וממשיכים בדיסקוס, ומה 6 תיקונים קטנים שונו בדרך.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
אני מתעורר סביב 4:30 a.m. לאחרונה, ממש לפני זריחת השמש, ומנותק מזה. ב-19 בספטמבר השתמשתי בבוקר זה כדי להתחיל מעבדה על Kitsune2, שכבת הרשת peer-to-peer מתחת ל-Holochain, וחיפשתי איפה היא מבלה זמן.עד 12:20 p.m., המעבדה יצרה 6 תיקונים. חיפושי נקודת קצה: 251× יותר מהיר ב10,000 זהויות שמורות. נתיב העדכון peer שמתקשר אליהם: 33× יותר מהיר. התחלת הדיסקוס לאחר משיכה מושלמת: 3,002 ms ל202 ms. תעבורת בקשות בורסט: 96.9% פחות הודעות. 3 מהשינויים שתקנו עבודה שהייתה ממתינה ללא צורך, או ממתינה למשהו שלא יקרה לעולם.אני כותב כבר יותר מ25 שנים ומבנה עם AI מאז GPT-3. אני משתמש בזה כדי לבודד משהו שמעניין אותי או שאני עדיין לא מבין, לעבוד עליו, ולבדוק מה אנחנו חושבים שלמדנו. אני אוהב את החלק הזה: להפוך שאלה לניסוי ולראות מה עומד. הבוקר הזה, עם סוכני קידוד AI, יישמתי את הגישה הזו למכונה שמאפשרת לצמתים של Holochain לשמור זה את זה מעודכן.יישומי Holochain משתפים נתונים בין מחשבים משתתפים, או nodes. כל משתתף שומר את היסטורייתו החתומה ומסייע לאמת ולשמור חלק מהנתונים המשותפים של היישום. החנות המשותפת הזו היא טבלת ההאש המפוזרת, או DHT. עותקים חיים עם כמה עמיתים, כך שהנתונים יכולים להישאר זמינים כאשר המחבר שלהם מתנתק. מדריך DHT של Holochain מסביר כיצד האחריות הללו מפוזרות.Kitsune2 מטפל בתקשורת עמית-אל-עמית שמתחת לזה. דמיין צומת שמתחיל להתעדכן: הוא לומד היכן ניתן להגיע לעמיתים, משווה מה הוא מחזיק עם מה שהם מחזיקים, ושואל עבור החלקים שחסרים לו. Gossip הוא החלפה שבה עמיתים מגלים את ההבדלים הללו; fetch מחזיר את הפעולות החסרות, יחידות הנתונים ש-Kitsune2 מעבירה. הצומת המקבל מחזיר אותן לאחסון הפעולות של המארח שלו. Holochain מטפל באימות ובאינטגרציה שלהן.Diagram source
graph TD
A[למד זהויות נקודות קצה של עמיתים] --> B[השווה נתונים דרך gossip]
B --> C[זיהוי פעולות חסרות]
C --> D[קח פעולות מהעמיתים]
D --> E[העבר פעולות שהתקבלו לאחסון המארח]
E --> F[איתן שהקצאות המתנה הושלמו]
F e1@--> B
e1@{ animation: fast }
Copy sourceהפאצ'ים יושבים לאורך הסדרה הזו. חלקם מפחיתים את העבודה שהצומת מבצע; אחרים מאפשרים לו להמשיך כאשר העבודה כבר הושלמה. המספרים לעיל מודדים את הצעדים הספציפיים הללו על צמתים מקומיים לבדיקה.
תיקנו את נקודת ההתחלה ב-commit העליון 06555ee, מקור הפיתוח 0.6.0-dev.1. כל השוואה משתמשת באותו בסיס ועוד רצף התיקונים הרשום. התוויות למטה מחברות את הממצאים לרשומות הניסוי שלנו; כל תיקוני 6 נשלחו כעת לסקירת העליון.
תווית
מה השתנה
תוצאה מדוד
K3a
לקרוא את עוזר הדליפה הקיים כאשר משיכת נתונים מסתיימת
יזום גוסיפ לאחר משיכת נתונים מושלמת: 3,002 → 202 ms
K3b
נעילת מקבל מוגדרת ל-dequeue
קונקורסיה אפקטיבית הייתה 1. עובדים מוגדרים כעת חופפים באמת
K3c
בעלות כניסה עם תג דגימה
ביטול שרשרת קוראים 0 מפתחות ממתינים. בסיס ממתין 8
K3d-P1
ניקוי תגובה מבוסס-סטים
1.9–6.1× עיבוד תגובה מהיר יותר בטעונות ממתינים גדולים
K3d-P2
קיבוץ שותפים זהים (ברירת מחדל 1)
פיצוצים: 87.5–96.9% פחות הודעות בקשה
K1
הפוך URL לאינדקס הסוכן
ב-10,000 זהויות שמורות: עדכונים 21–33×, חיפושים 118–251× מהירים יותר, עבור 3.10× זיכרון חנות
התיקון הראשון מחבר מחדש את השלמת האחזור למשימת הדיבור המתנה לה. השינוי קורא למתכנן קיים שמודיע למאזינים שהמפה הממתינה ריקה. בדקנו גם אחזור מושלם וגם אחזור שנשאר פתוח במכוון.
Gossip initiation after a fetch completes, with the control that must not move (ms)Chart data
milliseconds
Upstream 06555ee
With the drain notification restored
Fetch completed
3001
202
Fetch still pending (control)
3002
3001
לאחר השלמה, הדיבור יכול להמשיך. בזמן שהאחזור נשאר ממתין, שתי הגרסאות עדיין מגיעות למטמון הפ fallback. הבדיקה המבודדת למעלה מדידה 3,001 → 202 ms; השיחזור המשותף המאוחר יותר מדידת 3,002 → 202 ms. שניהם השתמשו fallback של 3,000 ms ועיכוב ראשוני של 200 ms. ההבדל המוערך של כ-15× רושם איזו מסלול לקח המשימה: המתנה ל-fallback או התעוררות בצלחת השלמה.
קופסה Rust היא חבילה של קוד. כל הפאץ' של 6 נמצאים בקופסה המרכזית, שמכילה את רשומות השותפים ואת מכשירי האחזור. הם משנים את אופן קבלת הגוסיפ של הנתונים והאותות של השלמה מבלי לערוך את אלגוריתם הגוסיפ או את התעבורה הרשתית הבסיסית. חבילה מוסיפה שדה תצורה מרכזי אופציונלי.
תווית
קובץ
שורות
K1
core/src/factories/core_known_peers.rs
+33 / −10
K3a
core/src/factories/core_fetch.rs
+1
K3b
core/src/factories/core_fetch.rs
+11 / −3
K3c
core/src/factories/core_fetch.rs
+71 / −53
K3d-P1
core/src/factories/core_fetch.rs
+6 / −1
K3d-P2
core/src/factories/core_fetch.rs, 1 קובץ בדיקה
+89 / −17
5 תיקונים מצטברים בסדר מוקלט על core_fetch.rs, אשר מבקשים פעולות חסרות ומעבדות תגובות. התיקון הנותר נמצא ב-core_known_peers.rs, הרישום השומר של איזה זהות משויכת לאיזה נקודת קצה של הרשת. לאחר מכן יישמנו את כל 6 על עץ מקור יחיד והפעלנו אותם יחד.
CoreFetch שומר מפה של הפעולות שביקש ומי ביקש אותן. כאשר תגובת חבר מגיעה והפעולות נשמרות בהצלחה, הקוד מסיר את המזהים מהמפה. חלקים אחרים בקובץ, נתיב שגיאת שליחה ונתיב ניקוי חבר, קוראים למתכנן בשם notify_listeners_if_queue_drained מיד לאחר הסרת הרשומות. נתיב ההצלחה לא קרא לו אף פעם.צומת יכול להרחיב את חלק ה-DHT שהוא מאחסן, שנקרא ארק האחסון שלו. כדי לעשות זאת, הוא צריך לתפוס את המידע בטווח הרחב יותר. בנתיב צמיחת הארק שבדקנו, gossip מחכה להשלים את האחזרות outstanding לפני יזום עם חבר, עם מונה כפתרון חלופי. המידע הגיע והמפה הממתינה ריקה, אך המשימה הממתינה לאותה נשארת ישנה עד שהמונה פג תוקף.Diagram source
sequenceDiagram
participant G as Gossip arc-growth loop
participant F as CoreFetch
participant P as Peer
G->>F: Register a drain waiter
P->>F: Final response, operations stored
F->>F: retain() empties the pending map
Note over F: helper exists, never called
F--xG: Notification that never arrives
G->>G: Initiate after the roughly 3-second fallback
Copy sourceבדיקה לאחר השלמה מסתירה את ההבדל: המתין חדש רואה את המפה הריקה ומחזיר מיד. רשמנו את שלנו לפני השלמה. ברגע שהנתונים נשמרו, הממתין עדיין לא קיבל התראה על הקוד המקורי; עם התיקון, קיבל אחת. זה מתקן את המעבר בין קבלת נתונים והתחלת החלפת שיח הבאה.בדקנו גם תגובות חלקיות, שגיאות אחסון, מספר מאזינים, ומאזינים שמרשמים כבקשות שהושלמו או שהגיע עבודה חדשה. תגובה חלקית חייבת להשאיר את הממתין במצב ממתין; רק השלמת הבקשה האחרונה הממתינה תעורר אותו.
הצד היוצא של CoreFetch מריץ מספר מוגדר של משימות עבודה שממשיכות משרשרת משותפת. הלולאה נכתבה כך:rustCopy source
while let Some(..) = outgoing_request_rx.lock().await.recv().await { // send the request}
המנעול מאפשר ל1 עובד לקחת את הבקשה הבאה מהתור המשותף. אך Rust שומר על המנעול הזמני הזה חי דרך גוף של while let זה, כולל המתנה לשליחת הרשת. בזמן ש1 עובד שלח, ה4 האחרים לא יכלו אפילו לאסוף את הבקשה הבאה שלהם. כל הבקשות עדיין יכולות להגיע בסופו של דבר, כך שניסוי משלוח יכול לעבור בזמן שהקונקורסיות המוגדרת לא בשימוש.העבירה את הקבלה לבלוק קצר כך שהמנעול משוחרר לפני שהשיחה מתחילה. עובדים עדיין מחלקים את האיסוף של בקשות, ואז שולחים אותן במקביל. שליחה איטית כבר לא מחזיקה את מנעול התור בזמן שעובדים אחרים מוכנים לבקשות.
Outgoing sends in flight at the same moment, by configured worker countChart data
concurrent sends observed
Upstream 06555ee
Dequeue-scoped guard
1 worker
1
1
2 workers
1
2
5 workers
1
5
המדידה מחזיקה כל שליחה פתוחה עם שעון מושהה ומחשבת כמה נכנסו לפני ששחרר אחד, ואז מאשרת שלא נכנס אף אחד מעבר לגבול המוגדר.
ביטול קורא השאיר את ה-node בהמתנה לפעולות שלא נשלחו של 8#
בקשת fetch עוברת דרך רשומות של 2: המפה המתנה אומרת מה ה-node מחכה, והתור היוצא מחזיק עבודה עבור עובדי השליחה. request_ops, המתודה שמבקשת פעולות, הוסיפה קבוצה שלמה למפה המתנה לפני שהמתינה למקום בתור זה.אם הקורא בוטל בזמן המתנה ליכולת, חלק מהפעולות כבר סומנו כמתנה למרות שלא קיבל עובד אותן. מילאנו את התור, ביטל קורא חסום, והותירנו את כל הבקשות המוכרות של 16,385 להסתיים. פעולות של 8 נשארו במצב המתנה. הן מעולם לא נכנסו לתור היוצא, לכן לא הייתה תגובה בדרך שלהם כדי לנקות אותן.זה מחבר ישירות לתיקון הראשון: הודעת השלמה לא יכולה להתריע בזמן שהמפה עדיין מכילה עבודה未סיימת. כאן, רישום עצמי של ה-node שמחזיק אותו בהמתנה.הפלאש שמקצה תחילה את יכולת התור, ואז רושם ומכניס את הפעולה לתור ללא await נוסף בין שלבים אלה. כל רשומה גם נושאת תג דורות, כך שהניקוי של שליחה שנכשלת ישנה לא מחק בקשה חדשה לאותה פעולה. עבודה שכבר נרשמה חיה את ביטול הקורא; עבודה עדיין בהמתנה לקבלת קבלה לא משאירה רשומה מתנה מאחור.זה מתקן בעלות של הבקשות. מגבלות זיכרון סך הכול נשארות שאלה עיצובית נפרדת, מכיוון שקורא עדיין יכול לספק קבוצה גדולה.
פחות הודעות בקשה, עם מגבלה על כמה כל אחת יכולה לגדול#
node שמנסה לעבור על קצב עשוי להזדקק להרבה פעולות מה‑peer זהה. פורמט הבקשה של Kitsune2 כבר תומך ברשימת מזהים, אבל הקוד היוצא שולח 1 לכל הודעה. לפני שילוב הבקשות האלו, בדקנו איך תגובות גדולות יותר יטופלו.עבור כל פעולה ממתינה, ניקוי התגובה סרק את רשימת המזהים שהוחזרו כדי לראות אם ניתן להסיר את הרשומה הזו. עם 8,192 רשומות ממתינות ו‑1,024 מזהים שהוחזרו, זה חוזר על חיפוש גדול. בניית HashSet של המזהים שהוחזרו עושה כל בדיקת חברות זולה; עיבוד התגובה נמדד 6.1× מהר יותר באותו מקרה. עם רק 16 מזהים שהוחזרו, אחסון הנתונים דומיננטי והשינוי הביא מעט.אז שילבנו בקשות מוכנות עבור אותו peer. ב‑burst של 64 פעולות קטנות, גדלי batch של 8 ו‑32 הפחיתו הודעות בקשה ב‑87.5% וב‑96.9%, בהתאמה.
Burst behaviour relative to the default batch size of 1 (percent of control)Chart data
percent of control
Request messages
Elapsed time
Batch 1 (control)
100
105.4
Batch 8
12.5
72.6
Batch 32
3.1
67.7
ה‑burst הסתיים כ‑27–32% מוקדם יותר. אותן פעולות עדיין נדרשו להעביר ולאחסן; החיסכון היה בכמה בקשות נשאו אותן. מדידת הבקרה batch‑1 הראתה 105.4% של זמן בסיס, מציגה כ‑5% דיפט זמן אפילו עם batching לא פעיל.עובד משלב רק בקשות שכבר מוכנות, כך שבקשה בודדת מעולם לא מחכה ל‑batch למלא. חלוקת batch משתמשת גם במגבלת מזהים מוגדרת וגם ב‑4,096‑byte encoded request threshold. ספירת פריטים לבדה לא מגבילה את גודל הכולל; הבדיקה עם 200 מזהים מחלקת אותם למספר הודעות מוגבלות. מזהה יחיד עדיין נשלח אם הוא בודד חורג מהמגבלה, לכן זה לא גבול גודל קו אוניברסלי. תגובות נושאות את הנתונים האמיתיים ויידרשו מגבלת גודל נפרדת על ה‑node המגיב.המועמד שומר על גודל ה־batch 1 כברירת מחדל ומקבל את התצורות הקיימות ללא שינוי. השארנו אפשרות לביצוע batchים גדולים יותר כי הבדיקה המבודדת של בקשה בודדת יצרה תוצאות שונות של עיכוב קצה, כפי שמפורט למטה.
הסרת הסריקה מסלול העדכון שווה ל33×, ו251× על החיפוש עצמו#
CoreKnownPeers זוכר זהויות ונקודות קצה רשת הקשורות אליהן. מספר זהויות יכולות לשתף נקודת קצה, וזהות חסומה עדיין צריכה להיות זיהית לאחר שהוסרה מאחסון העמיתים הפעילים. 10,000 זהויות שמורות פירושו היסטוריה של זהויות באחסון זה, לא 10,000 מחשבים מחוברים בו-זמנית.בעדכון מאגר העמיתים, בקרת גישה שואלת אילו זהויות שייכות לנקודת הקצה. החיפוש, get_by_url, סרק את המפה השמורה כולה בלוק כל פעם. ככל שההיסטוריה גדלה, עדכון מידע העמית הנוכחי נעשה יקר יותר.הוספנו אינדקס מנקודת קצה URL אל הזהויות הקשורות אליה: HashMap<Url, HashSet<AgentId>>. הרשומות המקוריות נשארות סמכותיות. כאשר זהות משנה נקודת קצה, האינדקס מעביר אותה למערך המתאים; החיפוש יכול אז ללכת ישירות למערך זה. שתי הגרסאות עברו את בדיקות התוצאה 19,422 המכסות עדכונים, פרסומים ישנים, הסרות, ונקודות קצה משותפות.
Microseconds per 16-advertisement update call (log scale)Chart data
microseconds per update call
retained identities
Upstream linear scan
Derived URL index
100
6.857
4.911
1,000
18.103
4.774
10,000
154.849
4.72
כל קריאה עם זמן מעלית מוסיפה 16 פרסומים ומריצה את מאזיני בקרת הגישה. ב10,000 זהויות שמורות, ירדה מ-155 µs ל4.72 µs, רווח 33× משותף. הגרסה המווסתת נשארת כמעט קבועה לאורך גדלים אלה מכיוון שהמאזינים הללו כבר לא סורקים את ההיסטוריה הגדלה.מדוד ב-API במקום דרך המתקשר, החיפוש עצמו עובר מסריקה לאלגוריתם hash. חוסר ב-10,000 זהויות שמורות ירד מ-11,423 ns ל-45 ns, רווח 251×, והצלחה יחידה מ-9,309 ns ל-79 ns, 118×. שאילתה שמחזירה הרבה זהויות עדיין מתרחבת לפי מה שהיא מחזירה, כך שהמקרה של shared-URL רווח 4.4× במקום 2 סדרי גודל. ה-251× הוא תוצאת החיפוש המבודדת. ה-33× מודד את קריאת העדכון הגדולה יותר שמשתמשת בו; רווחים אלה לא ניתן להוסיף או לכפול.
Requested store memory at 10,000 retained identities, by endpoint shapeChart data
megabytes
Upstream
With the index
Mixed endpoints
1.2
3.71
All shared
1.2
1.74
All URL-less
1.2
1.2
3.10× בחנות מעורבת, עוד 2.51 MB ב10,000 זהויות. כאשר כל זהות חולקת נקודת קצה המפה המופקת קטנה והעלות יורדת ל1.45×. כאשר אין לזהות URL אין מה להפיק והעלות היא אפס. המספרים הללו הם בתים שביקשו המקצה עבור החנות הנשמרת, לא זיכרון סה״כ של ה‑node.
עם כל התיקונים של 6 יחד, השרת יכול להשלים ולהמשיך#
ההפעלה המשותפת השתמשה ברשת האמיתית של Kitsune2's, בקשה, גישה לשותף, ורכיבי אחסון זיכרון, מתקשרת דרך מערכת ההעברה בדמיון של המערכת. הרצתנו רצף של שלבים של 5 על העצים המקוריים והתיקונים:
עדכון מידע שותף. זהות משנה נקודת קצה. מידע מיושן שמגיע מאוחר יותר משאיר את הרשומה החדשה intact, וזהות חסומה נשארת ניתנת לפתרון בקרת גישה. שתי הגרסאות עובדות; האינדקס שומר החלטות קיימות.
התחלת שיח אחרי שההורדה הושלמה. השרת המתוקן מתחיל אחרי 202 ms. המקור לוקח את נתיב הפallback ב3,002 ms.
קבלת נתונים בסדר לא נכון. פעולות מבוקשות של 3 מגיעות בתור תגובות של 4, כולל כפילות. שתי הגרסאות מאחסנות אותן באופן עקבי ומקשרות ספירת בתים לפעולה הנכונה.
השלמת ההורדה. הפעולות המאוחסנות ניתנות לשחזור. השרת המתוקן גם מעורר את המאזין שנרשם בזמן שהפעולות היו בתהליך.
המשך אחרי שותף כושל. כשל שליחה מבוקר מסיר את מצב הבקשה של השותף. שותף נוסף מספק את הפעולה, המפה המתוחכמת מתרוקנת, והורדה הבאה מצליחה. במקור, בדיקות השלמת ההודעה נכשלו.
בדיקות אינטראקציה נפרדות שילבו ביטול עם שליחות מקבילות ושילוב חבילות עם הודעת השלמה. התיקונים נשארו יחד: עבודה מאושרת הושלמה, קבלות מבוטלות לא השאירו רשומות יתומות, והמאזינים התעוררו אחרי התגובה הסופית.זה מביא אותנו עד שהנתונים התקבלו לאחסון המארח והשלב הבא של רשת יכול להמשיך. אימות ואינטגרציה של Holochain עדיין עוקבים מחוץ למעבדה זו. עדיין לא למדנו כמה שינויים אלה מקצינים את זמן ההתאמה המלא של צומת אמיתי.
המחיר של האינדקס צורך זיכרון ומעלה את עלות שינוי נקודת הקצה. בדיקת האחסון הקטן המקורי, עדכון קבוצת זהויות קבועה לכתובות URL חדשות רצה במהירות בסיסית של 0.946× עם זהויות שמורות100. ב10,000, כתיבה שמחליפה נקודת קצה נפרדת עלתה ב3.68× כמות. שמירה על האינדקס הנוסף עולה; החיסכון במיון חייב לשלם את זה.מכיוון שהפשרה הזו אמיתית, חיפשנו את העומס שבו האינדקס מאבד. 36 תצורות הוגדרו מראש לפני המדידה, 432 ריצות זוגיות בוצעו, והתמלילים התוצאות הוכנסו באותו אופן בין וריאנטים.
Paired speedup across the 36-config workload envelope, by mix (log scale)Chart data
paired speedup
retained identities
Steady, no rebind
100% rebind
Shared endpoints
URL-less heavy
100
1.61
1.47
1.42
1.09
1,000
7.2
6.26
4.12
2.13
10,000
55.56
36.42
5.55
12.16
Reference line, parity: 1
כל עומס במטריצה הרחבה הזו היה מתון מעל parity, כולל התערובת שבה כל עדכון מקובל שינה נקודת קצה: 1.47× ב100 זהויות ו36.42× ב10,000. העדכונים הללו גם מעוררים חיפושים של בקרת גישה, והחיסכון שלהם חרג מהכתיבות הנוספות. עומס רחב יותר זה שונה מהבדיקה הקודמת של קבוצת זהויות קבועה; תוצאות חיוביות שלו משאירות את הרגרסיה הקטנה הזו ברשומה.המקרה של 100 זהויות, רוב URL-ללא נשאר בלתי מסודר: המתון 1.09× כלל תוצאה זוגית מתחת ל parity. עדיין נדרשים עקבות מצמתים אמיתיים שמציגים ספירת זהויות שמורות, שינויים נקודת קצה, ותדירות חיפוש לפני המלצה על האינדקס לעומס מסוים.שליחת מקביל חשפה אינטראקציה לניקוי. כאשר העובדים יכלו להיפגש, ניקוי של שליחה שנכשל יכול היה לרוץ בזמן שאחרת בקשה לאותו עמית הייתה בתהליך. זה גרם לניקוי הכולל של עמית להיות רחב יותר מהעבודה שנכשלת. תיקון הבעלות מצמצם הסרת רשומות שעדיין שייכות לדור הבקשה הזה. בדיקת התיקונים יחד הייתה משמעותית כאן.זמן המתנה של בקשה בודדת של בatching נשאר בלתי מסודר. מדדנו p95, הזמן שבו 95% של בקשות מסתיימות. עבור בקשה שנשלחה לבד, הריצה הסופית של העובד הראתה 1.01–1.08× בסיסי p95; הריצה העצמאית הראתה 1.44–1.58×. התקנים אלה נוקטים עשרות מיקרו שניות, והבקרות שלהם גם נדחפו. שיפור הפיצוץ נוצר מחדש, אך תוצאת הבקשה הבודדת לא נרגעה, לכן תורים גדולים יותר נשארים אופציונליים.
בדקנו גם 2 חלקים אחרים של רצף ההתאמה זהה הזה. אף אחד מהם לא יצר תיקון מקובל.השוואת מה שכבר מחזיקים השותפים (K4). Gossip משתמש בסיכומים קומפקטיים של נתונים מאוחסנים כדי למצוא הבדלים. במבחן הגדול ביותר, יצירת והשוואת תמונת מצב שאינה משתנה חישבה 262,144 חתימות; חזרה על זה 10 פעמים יצרה פלט זהה בכל פעם. שימוש בסיכום קודם נראה מפתה, אך מחסן המארח יכול להשתנות ללא אות אמין לבטל את התוצאה המאוחסנת הזו. סיכום מטמון יכול אז להסתיר הבדל בין שותפים. האלטרנטיבות שהערכנו גם הן לא עמדו ב20% חיסכון הזמן הנדרש על מחסן בזיכרון. מדידות מחסן Holochain אמיתי הן החלק החסר הבא.שחזור כאשר שידור gossip נעצר (K2). קריאת המקור העלתה שאלה על שידור שמחזיק נעילה שהמשימה של זמן ההפסקה גם צריכה. גם נדרש לקבוע מה קורה לזרם התעבורה Iroh הבסיסי אם השידור הזה מבוטל בחלק מהדרך. ספק הסוכן חסם עבודה על מנהל ההדמיה, ולכן מבחן הריצה לא הושלם לעולם. זה נשאר דאגה שלא נבדקה, ללא תיקון או תוצאה אמינות.
ניסיונות אלה בוצעו על מקור פיתוח 0.6.0-dev.1, על Apple M4 Max משותף עם 16 ליבות לוגיות. השתמשנו בצמתים מקומיים ובשינויים בזיכרון, ללא קיבוע ליבה או מארח פיזי שני. התוצאות מכסות רכיבים שמות ויחסי הפעולה שלהם. מהירות רשת, התכנסות רשת מלאה, זיכרון צומת כולל, וזמן תגובה של יישום Holochain נשארים לא מדודים.השיטה עוקבת אחרי עבודתי על פיתוח מבוסס מדדים. רשמנו כל שאלה ומדד קבלה, שמרנו על המקור וההתקנים קבועים בכל השוואה, ושמרנו פקודות, דוגמאות וכשלים ברשומות רק-לוסון.עבור 3 תיקונים, אותם ניסיונות נכשלו בקוד המקורי באסרטציות הצפויות והצליחו עם התיקון. עבור האופטימיזציות, שתי הגרסאות נדרשו לשמר התנהגות, ואז המדידות נדרשו לעמוד בחריגה המוצהרת. ריצות זמן החלפו סדר ושמרו על הידור מחוץ לחלון המדידה. סוכן פיקוח הריץ מחדש פקודות קבלה על המקור הקפואה לפני קבלת כל תוצאה; הסכמה על זמן תגובה לבקשה בודדת נשארה בדוח הסופי.החבילה המושלמת מכילה 204 תיקיות קבלה. הניסיונות המשותפים התקבלו ב-12:17 בצהריים, והתוצאות הסופיות נרשמו ב-12:20 בצהריים. בדיקת סגירה סופית שימשה ב-2:38 בצהריים. כל 6 התיקונים פתוחים כעת לסקירת עליונה: הודעת השלמה, קונקורסנציה של עובדים, בעלות קבלה, ניקוי תגובה, אגרגציה של בקשות, ואינדקס נקודות קצה.
By me. המעבדה עצמה: שיטת הַמַּדָּד הַמְּדּוּשָׁה, ממוקדת ב‑Kitsune2 כדי לגלות היכן היא מְשַׁקֶּה זמן.By GPT-6 Astra. תיקוני התראת השלמה והבעלות על הכניסה: האבחון, התיקון, והבדיקות שנכשלות על הקוד המקורי. היא גם שיפרה את המאמר הזה מהיומיומיות של המעבדה.By GLM-5.3. תיקון תכנות מקביליות העובדים, ניקוי תגובות והצמדה, מטריצת עומס התצורה 36 עבור האינדקס, פרופיל סיכום DHT מאחורי השאלה הפתוחה K4, והחזרה המשותפת של כל תיקוני 6.By AI. אינדקס נקודת הקצה והמדידות שלו, סוכן פיקוח שחוזר על כל קבלה על מקור קפוי לפני שההוצאה נחשבת, והטיוטה הראשונה של מאמר זה.ביקורות שהחזיקו.
ממני: הטיוטה הסבירה מנגנונים פנימיים לפני שאמרה מה עשה צומת Holochain, ושאלות פתוחות 2 הגיעו ללא קשר לכל דבר. רצף העקיפה עכשיו מציג כל תיקון, וכל שאלה פתוחה נמצאת בשלב הרלוונטי.
מה‑AI: שאלתי אם הבוקר קיבל את המילה "breakthroughs". הוא טען שתיקון אינדקס נגזר ושיחה עזר שחוזרת הם תיקונים נכונים, לא טכניקות חדשות. המאמר מוגש כגילוי.
מ‑GPT-6 Astra: מספר טענות טיוטה חרגו מהקבלות שלהם. הוא קבע אותם למה שנמדד: 10,000 זהויות שמורות הן היסטוריה, לא 10,000 מחשבים מחוברים; עלות זיכרון האינדקס נשארת ברשומה; זמן המתנה לבקשה בודדת והדבר URL-less נשאר בלתי מספק.