← लेखों पर वापसखोजSeptember 19, 202616 मिनट में पढ़ेंCopy article

Kitsune2: खोजें 251x तेज़, अपडेट पथ 33x, और गपशप शुरू हुई 15x पहले

सुबह के प्रयोगों के भीतर Holochain के नेटवर्किंग लेयर पर: नोड्स कैसे साथियों को ढूंढते हैं, गायब डेटा प्राप्त करते हैं, और गपशप फिर से शुरू करते हैं, और क्या 6 छोटे पैच ने रास्ते में बदलाव किया.

Developed by Robert E. Beckner III (Merlin) | rbeckner.com

मैं हाल ही में 4:30 a.m. के आसपास जाग रहा हूँ, सूर्योदय से ठीक पहले, और इसका आनंद ले रहा हूँ. 19 सितंबर को मैंने उस सुबह का उपयोग Kitsune2 पर एक लैब शुरू करने के लिए किया, Holochain के नीचे का पीयर-टू-पीयर नेटवर्किंग लेयर, और खोजने गया कि यह कहाँ समय बिता रहा था.12:20 p.m. तक, लैब ने 6 पैच उत्पन्न किए. एंडपॉइंट खोजें: 251× तेज़ 10,000 बनाए रखी गई पहचानियों पर. वह पीयर-अपडेट पथ जो उन्हें कॉल करता है: 33× तेज़. गपशप आरंभ एक पूर्ण फ़ेच के बाद: 3,002 ms से 202 ms. बर्स्ट अनुरोध ट्रैफ़िक: 96.9% कम संदेश. 3 परिवर्तनों ने वह कार्य मरम्मत किया जो अनावश्यक रूप से प्रतीक्षा कर रहा था, या कुछ ऐसा जो कभी नहीं होगा उसकी प्रतीक्षा कर रहा था.मैं 25 वर्षों से कोडिंग कर रहा हूँ और GPT-3 से AI के साथ बना रहा हूँ. मैं इसका उपयोग किसी ऐसी चीज़ को अलग करने के लिए करता हूँ जिसकी मुझे परवाह है या जिसे मैं अभी तक नहीं समझता, उसे काम करके और यह परीक्षण करके कि हमने क्या सीखा है. मुझे वह हिस्सा पसंद है: एक प्रश्न को प्रयोग में बदलना और देखना कि क्या टिकता है. आज सुबह, AI कोडिंग एजेंट्स के साथ, मैंने उस दृष्टिकोण को Holochain नोड्स को एक-दूसरे को अपडेट रखने वाली मशीनरी पर लागू किया.Holochain अनुप्रयोग डेटा को भाग लेने वाले कंप्यूटरों, या nodes के बीच साझा करते हैं. प्रत्येक प्रतिभागी अपनी स्वयं की हस्ताक्षरित इतिहास रखता है और एप्लिकेशन के साझा डेटा के एक हिस्से को सत्यापित और संग्रहीत करने में मदद करता है. वह साझा स्टोर distributed hash table, या DHT है। प्रतियाँ कई समकक्षों के साथ रहती हैं, इसलिए डेटा उपलब्ध रह सकता है जब उसका लेखक ऑफ़लाइन हो जाए. Holochain's DHT guide बताता है कि ये ज़िम्मेदारियाँ कैसे वितरित की जाती हैं।Kitsune2 इस के नीचे पीयर-टू-पीयर संचार को संभालता है। एक नोड को पकड़ते हुए कल्पना करें: यह सीखता है कि समकक्ष कहाँ पहुँच सकते हैं, यह तुलना करता है कि उसके पास क्या है और उनके पास क्या है, और उन टुकड़ों के लिए पूछता है जो उसे नहीं हैं. Gossip वह विनिमय है जिसके माध्यम से समकक्ष उन अंतर को खोजते हैं; fetch अनुपलब्ध ऑपरेशनों को पुनः प्राप्त करता है, डेटा इकाइयाँ जिन्हें Kitsune2 स्थानांतरित करता है. प्राप्त करने वाला नोड उन्हें अपने होस्ट के ऑपरेशन स्टोर को सौंपता है।. Holochain उनकी सत्यापन और एकीकरण को संभालता है.

Diagram source

graph TD
    A[समकक्ष पहचान और एंडपॉइंट सीखें] --> B[गॉसिप के माध्यम से डेटा की तुलना करें]
    B --> C[अनुपलब्ध ऑपरेशनों की पहचान करें]
    C --> D[समकक्षों से ऑपरेशनों को प्राप्त करें]
    D --> E[प्राप्त ऑपरेशनों को होस्ट स्टोर को सौंपें]
    E --> F[संकेत दें कि लंबित फ़ेच पूरे हो गए हैं]
    F e1@--> B
    e1@{ animation: fast }

Copy sourceपैच उस अनुक्रम के साथ बैठते हैं. कुछ नोड द्वारा किए जाने वाले कार्य को कम करते हैं; अन्य इसे आगे बढ़ने देते हैं जब कार्य पहले ही समाप्त हो चुका हो. ऊपर के आंकड़े उन विशिष्ट चरणों को स्थानीय परीक्षण नोड्स पर मापते हैं.

प्रत्येक 6 परिवर्तन वास्तव में क्या ले गया#

हमने ऊपर की ओर कमिट 06555ee पर प्रारंभिक बिंदु तय किया, विकास स्रोत 0.6.0-dev.1। प्रत्येक तुलना उस आधाररेखा के साथ उपयोग करती है और दर्ज किए गए पैच अनुक्रम. नीचे के लेबल निष्कर्षों को हमारे प्रयोग रिकॉर्ड से जोड़ते हैं; सभी 6 पैच अब ऊपर की ओर समीक्षा के लिए सबमिट किए गए हैं.

लेबल	क्या बदला	मापा गया परिणाम
K3a	फ़ेच पूरा होने पर मौजूदा ड्रेन हेल्पर को कॉल करें	पूर्ण फ़ेच के बाद गॉसिप प्रारंभ: 3,002 → 202 ms
K3b	रिसीवर लॉक को डीक्यू पर स्कोप किया गया	प्रभावी समवर्तीता 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 datamilliseconds

	Upstream 06555ee	With the drain notification restored
Fetch completed	3001	202
Fetch still pending (control)	3002	3001

पूर्णता के बाद, गॉसिप आगे बढ़ सकता है. जबकि फ़ेच लंबित रहता है, दोनों संस्करण अभी भी फॉलबैक टाइमर तक पहुँचते हैं. ऊपर का पृथक परीक्षण मापा 3,001 → 202 ms; बाद का संयुक्त पुन: प्ले मापा 3,002 → 202 ms. दोनों ने एक 3,000 ms फॉलबैक और एक 200 ms प्रारंभिक विलंब का उपयोग किया. लगभग 15× अंतर रिकॉर्ड करता है कि कार्य ने कौन सा मार्ग लिया: फॉलबैक को समाप्त होने देना या पूर्णता पर जागना.

हर परिवर्तन एक ही क्रेट में रहता है, और 5 का 6 एक ही फ़ाइल में#

एक Rust क्रेट कोड का एक पैकेज है। सभी 6 पैच कोर क्रेट में रहते हैं, जिसमें पीयर रिकॉर्ड और फ़ेच मशीनरी शामिल है. वे गॉसिप को उसके डेटा और पूर्णता संकेत कैसे मिलते हैं, इसे बदलते हैं बिना गॉसिप एल्गोरिदम या अंतर्निहित नेटवर्क ट्रांसपोर्ट को संपादित किए. बैचिंग एक वैकल्पिक कोर कॉन्फ़िगरेशन फ़ील्ड जोड़ता है.

लेबल	फ़ाइल	पंक्तियाँ
K1	`core/src/factories/core_known_peers.rs`	+33 / −10
K3a	`core/src/factories/core_fetch.rs`	+1
के3ब	`core/src/factories/core_fetch.rs`	+11 / −3
के3स	`core/src/factories/core_fetch.rs`	+71 / −53
के3द-पी1	`core/src/factories/core_fetch.rs`	+6 / −1
के3द-पी2	`core/src/factories/core_fetch.rs`, 1 टेस्ट फ़ाइल	+89 / −17

5 पैच एक रिकॉर्डेड क्रम में core_fetch.rs पर स्टैक किए गए हैं, जो गायब ऑपरेशन्स का अनुरोध करते हैं और प्रतिक्रियाओं को प्रोसेस करते हैं। शेष पैच core_known_peers.rs में स्थित है, जो यह रिकॉर्ड रखता है कि कौन सी पहचान किस नेटवर्क एंडपॉइंट से जुड़ी है। फिर हमने सभी 6 को एक ही स्रोत ट्री पर लागू किया और उन्हें साथ में चलाया.

डेटा पहुँच गया था, लेकिन गॉसिप अभी भी प्रतीक्षा कर रहा था#

CoreFetch उन ऑपरेशनों का मानचित्र रखता है जिनके लिए उसने अनुरोध किया है और किससे। जब किसी पीयर का उत्तर आता है और ऑपरेशन्स सफलतापूर्वक संग्रहीत हो जाते हैं, तो कोड उन पहचानकर्ताओं को मानचित्र से हटा देता है. फ़ाइल के अन्य हिस्से, send-error पथ और पीयर-क्लीनअप पथ, एक हेल्पर जिसे notify_listeners_if_queue_drained कहा जाता है, को हटाने के तुरंत बाद बुलाते हैं। सफलता पथ ने इसे कभी नहीं बुलाया.एक नोड DHT के उस हिस्से को विस्तारित कर सकता है जिसे वह संग्रहीत करता है, जिसे उसका storage arc कहा जाता है. इसके लिए, उसे बड़े रेंज के भीतर डेटा के साथ पकड़ बनानी होती है. आर्क-ग्रोथ पथ में हमने परीक्षण किया, गॉसिप आउटस्टैंडिंग फ़ेचेज़ के समाप्त होने तक प्रतीक्षा करता है, फिर एक पीयर के साथ आरंभ करता है, टाइमर को फॉलबैक के रूप में उपयोग करते हुए. डेटा पहुँच गया और पेंडिंग मानचित्र खाली हो गया, लेकिन उस संकेत के लिए प्रतीक्षा कर रहा कार्य तब तक सोता रहा जब तक टाइमर समाप्त नहीं हुआ.

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पूर्णता के बाद जाँच अंतर को छिपाती है: एक नया पंजीकृत वेटर खाली मानचित्र देखता है और तुरंत लौटता है. हमने अपना पहले पंजीकरण किया. एक बार डेटा संग्रहीत हो जाने पर, उस वेटर को मूल कोड पर कोई सूचना नहीं मिली; पैच के साथ, उसे एक मिली. यह डेटा प्राप्त करने और अगले गपशप विनिमय को शुरू करने के बीच के हस्तांतरण को ठीक करता है.हमने आंशिक प्रतिक्रियाएँ, स्टोर त्रुटियाँ, कई श्रोता, और श्रोता जो अनुरोध पूर्ण होने या नया कार्य आने पर पंजीकृत होते हैं, भी जाँच की. एक आंशिक प्रतिक्रिया को वेटर को लंबित छोड़ना चाहिए; केवल अंतिम बकाया फ़ेच को पूरा करने से ही उसे जगाना चाहिए.

5 कार्यकर्ता कॉन्फ़िगर किए गए थे, और 1 वास्तव में भेज रहा था#

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 count

Chart dataconcurrent sends observed

	Upstream 06555ee	Dequeue-scoped guard
1 worker	1	1
2 workers	1	2
5 workers	1	5

माप प्रत्येक भेजने को एक रुकी हुई घड़ी के साथ खुला रखता है और गिनता है कि कितने प्रवेश करते हैं इससे पहले कि कोई भी रिलीज़ हो, फिर पुष्टि करता है कि कॉन्फ़िगर की गई सीमा से आगे कभी कोई प्रवेश नहीं करता.

एक कॉलर को रद्द करने से नोड 8 अनभेजी ऑपरेशनों का इंतज़ार करता रहा#

एक फ़ेच अनुरोध 2 रिकॉर्ड्स के माध्यम से गुजरता है: लंबित मैप बताता है कि नोड किसका इंतज़ार कर रहा है, और आउटगोइंग कतार भेजने वाले कार्यकर्ताओं के लिए काम रखती है. request_ops, वह विधि जो ऑपरेशनों के लिए पूछती है, ने उस कतार में जगह के लिए प्रतीक्षा करने से पहले लंबित मैप में एक पूरा बैच जोड़ दिया।यदि कॉलर क्षमता के लिए प्रतीक्षा करते समय रद्द कर दिया गया, तो कुछ ऑपरेशनों को पहले ही लंबित के रूप में चिह्नित किया गया था, भले ही कोई कार्यकर्ता उन्हें प्राप्त नहीं कर रहा था. हमने कतार भरी, एक अवरुद्ध कॉलर को रद्द किया, और सभी 16,385 स्वीकृत अनुरोधों को समाप्त होने दिया. 8 ऑपरेशन्स अभी भी लंबित रहे। वे कभी आउटगोइंग कतार में प्रवेश नहीं किए, इसलिए उन्हें साफ़ करने के रास्ते में कोई प्रतिक्रिया नहीं थी.यह सीधे पहले मरम्मत से जुड़ता है: एक पूर्णता सूचना तब फायर नहीं हो सकती जब मैप अभी भी अधूरी कार्य रखता है. यहाँ, नोड का स्वयं का बहीखाता इसे इंतज़ार में रख रहा था.पैच पहले कतार क्षमता आरक्षित करता है, फिर रिकॉर्ड करता है और ऑपरेशन को बिना किसी अन्य await के उन चरणों के बीच एन्क्यू करता है. प्रत्येक प्रविष्टि में एक पीढ़ी टैग भी होता है, इसलिए पुराने असफल भेज से सफ़ाई उसी ऑपरेशन के लिए नए अनुरोध को मिटा नहीं सकती. पहले से स्वीकृत काम कॉलर के रद्दीकरण से बचता है; अभी भी स्वीकृति की प्रतीक्षा कर रहा काम कोई लंबित प्रविष्टि पीछे नहीं छोड़ता.यह अनुरोधों के स्वामित्व की मरम्मत करता है. कुल मेमोरी सीमाएँ एक अलग डिजाइन प्रश्न बनी रहती हैं, क्योंकि एक कॉलर अभी भी एक बड़ा बैच प्रदान कर सकता है.

कम अनुरोध संदेश, प्रत्येक के लिए अधिकतम आकार पर सीमा के साथ#

एक कैचिंग-अप नोड को उसी पीयर से कई ऑपरेशन्स की आवश्यकता हो सकती है. Kitsune2 का अनुरोध प्रारूप पहले से ही पहचानकर्ताओं की सूची का समर्थन करता है, लेकिन आउटगोइंग कोड प्रत्येक संदेश के लिए 1 भेजता है. उन अनुरोधों को संयोजित करने से पहले, हमने जांचा कि बड़े प्रतिक्रियाओं को कैसे संभाला जाएगा.प्रत्येक पेंडिंग ऑपरेशन के लिए, प्रतिक्रिया सफ़ाई लौटाए गए पहचानकर्ताओं की सूची को स्कैन करती है यह देखने के लिए कि क्या वह प्रविष्टि हटा सकती है. 8,192 पेंडिंग प्रविष्टियों और 1,024 लौटाए गए पहचानकर्ताओं के साथ, यह बड़ी मात्रा में खोज को दोहराता है. लौटाए गए पहचानकर्ताओं का एक HashSet बनाना प्रत्येक सदस्यता जाँच को सस्ता बनाता है; प्रतिक्रिया प्रसंस्करण उस मामले में 6.1× तेज़ मापा गया। केवल 16 लौटाए गए पहचानकर्ताओं के साथ, डेटा संग्रहीत करना प्रमुख था और परिवर्तन ने कम लाभ दिया.फिर हमने उसी पीयर के लिए तैयार अनुरोधों को संयोजित किया. 64 छोटे ऑपरेशन्स के एक बर्स्ट में, 8 और 32 के बैच आकार ने अनुरोध संदेशों को क्रमशः 87.5% और 96.9% तक घटाया, प्रत्येक के लिए.

Burst behaviour relative to the default batch size of 1 (percent of control)

Chart datapercent of control

	Request messages	Elapsed time
Batch 1 (control)	100	105.4
Batch 8	12.5	72.6
Batch 32	3.1	67.7

बर्स्ट लगभग 27–32% पहले समाप्त हुआ. वही ऑपरेशन्स अभी भी स्थानांतरित और संग्रहीत होने चाहिए थे; बचत यह थी कि कितने अनुरोधों ने उन्हें वहन किया. बैच-1 नियंत्रण ने बेसलाइन बीते समय का 105.4% मापा, यह दिखाते हुए कि बैचिंग निष्क्रिय होने पर भी लगभग 5% टाइमिंग ड्रिफ्ट है.एक वर्कर केवल उन अनुरोधों को संयोजित करता है जो पहले से तैयार हैं, इसलिए एक अकेला अनुरोध कभी भी बैच भरने का इंतज़ार नहीं करता. बैच विभाजन दोनों एक कॉन्फ़िगर किए गए पहचानकर्ता सीमा और एक 4,096-byte एन्कोडेड अनुरोध थ्रेशोल्ड का उपयोग करता है. केवल आइटमों की गिनती उनके कुल आकार को सीमित नहीं करती; 200 पहचानकर्ताओं के साथ परीक्षण उन्हें कई सीमित संदेशों में विभाजित करता है. एक एकल पहचानकर्ता अभी भी भेजा जाता है यदि वह अकेला उस थ्रेशोल्ड से अधिक हो, इसलिए यह एक सार्वभौमिक वायर-साइज़ सीमा नहीं है. प्रतिक्रियाएँ वास्तविक डेटा ले जाती हैं और प्रतिक्रिया देने वाले नोड पर एक अलग आकार सीमा की आवश्यकता होगी.उम्मीदवार बैच आकार 1 को अपने डिफ़ॉल्ट के रूप में रखता है और मौजूदा कॉन्फ़िगरेशन को अपरिवर्तित स्वीकार करता है. हमने बड़े बैचों को ऑप्ट‑इन छोड़ दिया क्योंकि एकल अनुरोध के लिए अलग परीक्षण ने असंगत टेल‑लेटेंसी परिणाम उत्पन्न किए, जो नीचे कवर किए गए हैं.

अपडेट पथ से स्कैन को हटाना 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 datamicroseconds 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 पर मापा गया बजाय कॉलर के माध्यम से, लुकअप स्वयं एक स्कैन से हैश में बदल जाता है। 10,000 रखी गई पहचानियों पर एक मिस 11,423 ns से 45 ns तक गिर गया, एक जोड़ी 251×, और एक एकल हिट 9,309 ns से 79 ns तक, 118×. एक क्वेरी जो कई पहचानियाँ लौटाती है, अभी भी लौटाए गए के साथ स्केल करती है, इसलिए साझा-URL केस 2 ऑर्डर के बजाय 4.4× लाभ देता है। 251× अलग‑थलग लुकअप परिणाम है. 33× बड़े अपडेट कॉल को मापता है जो इसका उपयोग करता है; ये लाभ जोड़े या गुणा नहीं किए जा सकते.

Requested store memory at 10,000 retained identities, by endpoint shape

Chart datamegabytes

	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 नहीं होता, तो व्युत्पन्न करने के लिए कुछ नहीं होता और लागत शून्य है। ये संख्याएँ आवंटक-आवश्यक बाइट्स हैं रखे हुए स्टोर के लिए, कुल नोड मेमोरी नहीं.

सभी 6 पैच एक साथ होने पर, नोड समाप्त कर सकता है और जारी रख सकता है#

संयुक्त पुन:प्रयोग ने Kitsune2 के वास्तविक गॉसिप, फ़ेच, पीयर-एक्सेस, और मेमोरी-स्टोर घटकों का उपयोग किया, अपने इन-मेमोरी टेस्ट ट्रांसपोर्ट के माध्यम से संचार करते हुए. हमने मूल और पैच किए गए स्रोत वृक्षों पर एक 5-चरण अनुक्रम चलाया:

पीयर जानकारी अपडेट करें। एक पहचान एंडपॉइंट बदलती है. बाद में आने वाली पुरानी जानकारी नए रिकॉर्ड को बरकरार रखती है, और एक अवरुद्ध पहचान अभी भी एक्सेस नियंत्रण के लिए हल करने योग्य रहती है. दोनों संस्करण पास होते हैं; सूचकांक मौजूदा निर्णयों को बनाए रखता है.
फ़ेच पूरा होने के बाद गॉसिप शुरू करें। पैच किया गया नोड 202 ms के बाद आरंभ होता है. मूल 3,002 ms पर फॉलबैक पथ लेता है.
डेटा को क्रम से बाहर प्राप्त करें। 3 अनुरोधित ऑपरेशन्स 4 प्रतिक्रियाओं के रूप में आते हैं, जिसमें एक डुप्लिकेट भी शामिल है. दोनों संस्करण उन्हें लगातार संग्रहीत करते हैं और बाइट काउंट को सही ऑपरेशन के साथ जोड़ते हैं.
फ़ेच समाप्त करें। संग्रहीत ऑपरेशन्स को पुनः प्राप्त किया जा सकता है. पैच किया गया नोड उन ऑपरेशन्स के दौरान पंजीकृत लिस्नर को भी जगाता है.
असफल पीयर के बाद जारी रखें। नियंत्रित भेजने की विफलता उस पीयर की अनुरोध स्थिति को साफ़ करती है. दूसरा पीयर ऑपरेशन प्रदान करता है, पेंडिंग मैप खाली हो जाता है, और एक बाद का फ़ेच सफल होता है. मूल पर, पूर्णता-सूचना जाँच विफल हो जाती है.

अलग-अलग इंटरैक्शन परीक्षणों ने रद्दीकरण को समवर्ती भेजों और संयुक्त बैचिंग को पूर्णता सूचना के साथ संयोजित किया. मरम्मतें एक साथ बनी रहीं: स्वीकृत कार्य पूरा हुआ, रद्द की गई स्वीकृतियों ने कोई परित्यक्त प्रविष्टि नहीं छोड़ी, और लिस्नर अंतिम प्रतिक्रिया के बाद जागे.यह हमें डेटा को होस्ट स्टोर में प्राप्त करने और अगले नेटवर्किंग चरण को आगे बढ़ने योग्य बनाने तक ले जाता है. Holochain का सत्यापन और एकीकरण अभी भी इस प्रयोगशाला के बाहर अनुसरण करते हैं. हमें अभी तक मापना बाकी है कि ये बदलाव एक वास्तविक नोड के पूर्ण कैच-अप समय को कितना कम करते हैं.

प्रत्येक लाभ की लागत#

इंडेक्स मेमोरी लेता है और एंडपॉइंट परिवर्तनों को अधिक महंगा बनाता है। मूल छोटे-स्टोर परीक्षण में, नई URLs पर एक निश्चित सेट की पहचानें अपडेट करने से 0.946× आधारभूत गति पर चलाया गया 100 रखी गई पहचानें. 10,000 पर, एक अलग एंडपॉइंट-परिवर्तन लिखने की लागत 3.68× थी. अतिरिक्त इंडेक्स बनाए रखने की एक कीमत है; लुकअप बचत को इसे चुकाना चाहिए.क्योंकि वह ट्रेड-ऑफ वास्तविक है, हम उस कार्यभार की तलाश में गए जहाँ इंडेक्स खो देता है. 36 कॉन्फ़िगरेशन मापने से पहले पूर्व-घोषित थे, 432 जोड़े हुए रन निष्पादित हुए, और परिणाम प्रतिलेख वेरिएंट्स के बीच समान रूप से हैश किए गए थे.

Paired speedup across the 36-config workload envelope, by mix (log scale)

Chart datapaired 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

इस व्यापक मैट्रिक्स में हर कार्यभार का माध्यिका समता से ऊपर था, जिसमें वह मिश्रण भी शामिल है जहाँ हर स्वीकार्य अपडेट एक एंडपॉइंट बदलता है: 1.47× पर 100 पहचानें और 36.42× पर 10,000. उन अपडेट्स ने पहुँच-नियंत्रण लुकअप भी ट्रिगर किए, और उनकी बचत अतिरिक्त लिखने से अधिक थी. यह व्यापक कार्यभार पहले के निश्चित-सेट परीक्षण से अलग है; इसका सकारात्मक परिणाम उस छोटे-स्टोर प्रतिगमन को रिकॉर्ड पर छोड़ देता है.100-पहचान, अधिकांश URL-विरहित मामला अभी भी अनिर्णायक है: इसका 1.09× माध्यिका एक जोड़े हुए परिणाम को समता से नीचे शामिल करता है। हमें अभी भी वास्तविक नोड्स से ट्रेस की आवश्यकता है जो रखी गई पहचान गिनती, एंडपॉइंट परिवर्तन, और लुकअप आवृत्ति दिखाते हैं, इससे पहले कि किसी विशेष कार्यभार के लिए इंडेक्स की सिफारिश की जाए.समानांतर भेजने ने एक सफाई इंटरैक्शन उजागर किया। एक बार जब कार्यकर्ता ओवरलैप कर सकते थे, तो एक विफल भेजने के लिए सफाई चल सकती थी जबकि उसी पीयर के लिए एक अन्य अनुरोध उड़ान में था. इससे मौजूदा पीयर-व्यापी सफाई उस कार्य से व्यापक हो गई जो विफल हुआ था. स्वामित्व पैच ने हटाने को उन प्रविष्टियों तक सीमित कर दिया जो अभी भी उस अनुरोध पीढ़ी से संबंधित थीं. पैचों को एक साथ परीक्षण करना यहाँ महत्वपूर्ण था.बैचिंग का एकल-रिक्वेस्ट विलंबता अभी भी अनिर्णायक है। हमने p95 मापा, वह समय जिसके भीतर 95% अनुरोध समाप्त होते हैं. एक अकेले भेजे गए अनुरोध के लिए, कार्यकर्ता का अंतिम रन दिखाया 1.01–1.08× आधारभूत p95; स्वतंत्र पुनःरन ने दिखाया 1.44–1.58×. इन फिक्स्चर को दर्जनों माइक्रोसेकंड लगते हैं, और उनके नियंत्रण भी ड्रिफ्ट हुए. बर्स्ट सुधार पुन: उत्पन्न हुआ, लेकिन अकेले अनुरोध का परिणाम स्थिर नहीं हुआ, इसलिए बड़े बैच अभी भी चयनित रहते हैं.

बार‑बार तुलना और रोके गए भेजे खुले रहते हैं#

हमने उसी कैच‑अप अनुक्रम के 2 अन्य भागों की भी जाँच की. किसी ने भी स्वीकार्य पैच उत्पन्न नहीं किया.जो समकक्ष पहले से रखते हैं (K4) की तुलना करना। गॉसिप संग्रहीत डेटा के संक्षिप्त सारांशों का उपयोग करके अंतर खोजता है. सबसे बड़े परीक्षण में, एक अपरिवर्तित स्नैपशॉट का उत्पादन और तुलना करने से 262,144 हैश बने; इसे 10 बार दोहराने पर हर बार समान आउटपुट मिला. एक पूर्व सारांश का पुन: उपयोग आकर्षक लगता है, लेकिन होस्ट स्टोर बिना किसी विश्वसनीय संकेत के बदल सकता है जो उस सहेजे गए परिणाम को अमान्य करता है. एक कैश्ड सारांश तब समकक्षों के बीच अंतर को छिपा सकता है. जिन विकल्पों का हमने मूल्यांकन किया, वे भी आवश्यक 20% समय बचत को इन‑मेमोरी स्टोर पर पूरा नहीं कर सके. वास्तविक Holochain स्टोर से माप अगले गायब टुकड़े हैं.जब गॉसिप भेजना रुक जाता है तो पुनर्प्राप्ति (K2)। स्रोत पढ़ने से एक प्रश्न उठता है कि क्या भेजने से एक लॉक हो रहा है जिसे टाइमआउट कार्य को भी चाहिए. हमें यह भी स्थापित करना था कि यदि वह भेजा बीच में रद्द किया जाता है तो अंतर्निहित Iroh ट्रांसपोर्ट स्ट्रीम के साथ क्या होता है. एजेंट प्रोवाइडर ने पुनरुत्पादन ड्राइवर पर काम को अवरुद्ध कर दिया, इसलिए रनटाइम परीक्षण कभी पूरा नहीं हुआ. यह अभी भी एक अनपरीक्षित चिंता है, बिना किसी पैच या विश्वसनीयता परिणाम के.

हमने क्या मापा, और क्या मापना बाकी है#

ये प्रयोग विकास स्रोत 0.6.0-dev.1 पर चले, 1 साझा Apple M4 Max के साथ 16 तार्किक कोर पर। हमने स्थानीय परीक्षण नोड्स और इन‑मेमोरी ट्रांसपोर्ट्स का उपयोग किया, बिना कोर पिनिंग या दूसरे भौतिक होस्ट के. परिणाम नामित घटकों और उनके अंतःक्रियाओं को कवर करते हैं. नेटवर्क थ्रूपुट, पूरे नेटवर्क का संमिलन, कुल नोड मेमोरी, और होलोचेन एप्लिकेशन विलंबता अभी तक मापी नहीं गई है.यह विधि मेरे बेंचमार्क‑ड्रिवेन विकास पर काम का अनुसरण करती है। हमने प्रत्येक प्रश्न और स्वीकृति सीमा को रिकॉर्ड किया, स्रोत और फ़िक्स्चर को प्रत्येक तुलना के भीतर स्थिर रखा, और कमांड, नमूने, और विफलताओं को केवल-ऐड रिसीट्स में रखा.3 मरम्मतों के लिए, वही परीक्षण मूल कोड पर अपेक्षित दावे पर विफल हुए और पैच के साथ पास हुए. अनुकूलनों के लिए, दोनों संस्करणों को व्यवहार बनाए रखना था, फिर मापों को बताई गई सीमा को पूरा करना था. टाइमिंग रन क्रम को बदलते थे और संकलन को मापे गए विंडो के बाहर रखते थे. एक पर्यवेक्षण एजेंट ने फ्रोज़न स्रोत पर स्वीकृति कमांड को फिर से चलाया, प्रत्येक परिणाम को स्वीकार करने से पहले; अकेले‑अनुरोध विलंबता पर असहमति अंतिम रिपोर्ट में बनी रही.पूर्ण पैकेज में 204 रसीद निर्देशिकाएँ शामिल हैं. संयुक्त परीक्षण 12:17 p.m. पर स्वीकार किए गए, और टर्मिनल परिणाम 12:20 p.m. पर दर्ज किए गए। अंतिम समापन जाँच 2:38 p.m. पर रखी गई। सभी 6 पैच अब अपस्ट्रीम समीक्षा के लिए खुले हैं: completion notification, worker concurrency, admission ownership, response cleanup, request batching, और endpoint indexing.

प्रमुख श्रेय#

मेरे द्वारा। प्रयोगशाला स्वयं: मेरा benchmark-driven विधि, Kitsune2 पर लक्षित करके यह पता लगाने के लिए कि यह समय कहाँ खर्च कर रहा था.GPT-6 Astra द्वारा। पूर्णता-सूचना और स्वीकृति-स्वामित्व मरम्मत: निदान, पैच, और मूल कोड पर विफल होने वाले परीक्षण. इसने प्रयोगशाला रिकॉर्ड से इस लेख को भी परिष्कृत किया.GLM-5.3 द्वारा। कार्यकर्ता-सहवर्ती मरम्मत, प्रतिक्रिया सफाई और बैचिंग, सूचकांक के लिए 36-कॉन्फ़िगरेशन कार्यभार मैट्रिक्स, खुला K4 प्रश्न के पीछे DHT सारांश प्रोफाइलिंग, और सभी 6 पैच का संयुक्त पुनःप्रदर्शन.AI द्वारा। एंडपॉइंट सूचकांक और इसके माप, एक पर्यवेक्षक एजेंट जिसने प्रत्येक स्वीकृति को फ्रोज़न स्रोत पर फिर से चलाया इससे पहले कि परिणाम गिना जाए, और इस लेख का पहला मसौदा.रहने वाले आलोचनाएँ।

मेरे अनुसार: मसौदा आंतरिक तंत्रों को समझाता है इससे पहले कि यह बताता कि एक Holochain नोड क्या कर रहा था, और 2 खुली प्रश्न बिना किसी संबंध के आए. कैच‑अप अनुक्रम अब हर पैच को प्रस्तुत करता है, और प्रत्येक खुला प्रश्न उस चरण पर स्थित है जिस पर यह लागू होता है.
AI से: मैंने पूछा कि क्या सुबह को "breakthroughs" शब्द मिला। उसने तर्क दिया कि एक व्युत्पन्न सूचकांक और एक बहाल सहायक कॉल सही सुधार हैं, नई तकनीकें नहीं. लेख को एक खोज के रूप में फाइल किया गया है.
GPT-6 Astra से: कई मसौदा दावे उनके रसीदों से आगे निकल गए. उसने उन्हें मापे गए पर रखा: 10,000 रखे गए पहचानें एक इतिहास हैं, 10,000 जुड़े कंप्यूटर नहीं; सूचकांक की मेमोरी लागत रिकॉर्ड पर रहती है; एकल‑अनुरोध विलंबता और अधिकांश URL‑कम केस निष्कर्षहीन रहते हैं।

साथ में पहुँचे। कैच‑अप अनुक्रम जिसे लेख अनुसरण करता है: एक नोड अपने समकक्षों को सीखता है, जो रखता है उसकी तुलना करता है, जो कमी है उसे प्राप्त करता है, उसे संग्रहीत करता है, और जारी रखता है, प्रत्येक पैच उस चरण पर रखा जाता है जिसे यह बदलता है.निर्मित। Holochain कोर टीम के बदलने योग्य घटक फ़ैक्टरी और इन‑मेमोरी ट्रांसपोर्ट, जो प्रयोगशाला को इन व्यवहारों को वास्तविक Kitsune2 घटकों में परीक्षण करने देते हैं.#benchmarking#distributed-systems#rust#performance#AI#agents#open-source#experiential#insights—Robert E. Beckner III (Merlin)पढ़ना जारी रखेंपिछलाबुद्धिमत्ता आज्ञा नहीं मान सकती: निर्णय, प्राधिकरण, और अस्वीकृति क्या दर्शाती है अगलाप्रॉम्प्ट कैशिंग की गलतियाँ आपके संगठन को हर AI टर्न पर लगभग 6x अधिक खर्च करा सकती हैं Qwen 3.8-27B एक M1 Ultra पर: 12.1 से 20.3 टोकन/सेकंड तक सब कुछ मापकरखोजAugust 14, 20268 मिनट में पढ़ें MTPLX एक M1 Ultra पर: वह 25 टोक/सेक Tune That Served 16.5खोजAugust 15, 20268 मिनट में पढ़ें अंतिम CLI: पुनर्निर्माण Base 51 के खिलाफ मेरे उपकरण बनाए गएखोजAugust 19, 202611 मिनट में पढ़ेंसंबंधित परियोजनाएँ175-पृष्ठ चीनी हस्तलिपिएआई नवाचार AIA - एआई सलाहकारएआई नवाचार