WASM बनाम कंटेनर कोल्ड स्टार्ट: रनटाइम क्या कहता है

यह अंग्रेजी पाठ फ़्रेंच मूल से स्वचालित रूप से उत्पन्न हुआ था और अभी तक इसकी समीक्षा नहीं की गई है।

यह पृष्ठ स्वचालित रूप से अनुवादित किया गया था. अंग्रेजी संस्करण प्रामाणिक है.

This article brings together what identifiable third-party sources publish about WebAssembly's cold start compared to containers: a paper presented at USENIX NSDI, official documentation from Fastly, WasmEdge and Wasmer, and an academic research project on serverless isolation. No Aurabase figures are included. Our edge functions run well on Wasmtime, verified in the repository, but no cold start benchmark specific to our infrastructure has been published to date, a distinction detailed below. For the general benchmarking method applied elsewhere on this blog, see our pillar article onbenchmarking methodology.

अनिवार्य है

AWS फायरक्रैकर पेपर (Agache et al., USENIX NSDI 2020) 125 एमएस के तहत एक माइक्रोवीएम स्टार्टअप और 5 MiB के तहत एक मेमोरी ओवरहेड का दस्तावेजीकरण करता है: इस लेख में सबसे सटीक मात्रात्मक संदर्भ।
2019 में इसके एओटी ल्यूसेट रनटाइम (जिसके अनुकूलन को वास्मटाइम में विलय कर दिया गया था) के लिए एक मिलीसेकंड से कम के WASM इंस्टेंटेशन समय को तेजी से प्रलेखित किया गया। यह आपूर्तिकर्ता द्वारा प्रकाशित एक आंकड़ा है, यहां परामर्श किए गए स्रोतों में कभी भी स्वतंत्र रूप से पुन: प्रस्तुत नहीं किया गया है।
सीएनसीएफ गवर्नेंस के तहत एक परियोजना, वास्मएज ने अपने आधिकारिक दस्तावेज में दावा किया है कि इस लेख में उद्धृत स्वतंत्र प्रति-उपायों के बिना, समकक्ष डॉकर कंटेनर की तुलना में काफी कम स्टार्टअप और मेमोरी फ़ुटप्रिंट है।
वासटाइम, वासमर और वासमएज एक ही तरीके से संकलित नहीं होते हैं (क्रेनलिफ्ट, सिंगलपास/क्रेनलिफ्ट/अपनी पसंद का एलएलवीएम, अपना एओटी कंपाइलर): बैकएंड की यह पसंद उनके प्रकाशित आंकड़ों के बीच अंतर का एक अच्छा हिस्सा बताती है, न कि केवल रनटाइम की तरह।
ऑराबेस अपने एज फ़ंक्शंस के लिए उत्पादन में वास्मटाइम का उपयोग करता है, जिसे aura-functions/Cargo.tomlमें सत्यापित किया गया है, लेकिन आज तक अपने स्वयं के बुनियादी ढांचे पर मापा गया कोई कोल्ड स्टार्ट आंकड़े प्रकाशित नहीं करता है।

सूत्रों पर विधि नोट

नीचे उद्धृत तृतीय-पक्ष स्रोतों को उनके शीर्षक, उनके लेखक या प्रकाशक और उनकी प्रकाशन तिथि से पहचाना जा सकता है। यह शोध वेबअसेंबली और सर्वर रहित पारिस्थितिकी तंत्र में मान्यता प्राप्त और व्यापक रूप से प्रलेखित प्रकाशनों पर निर्भर करता है, न कि लेखन के समय उनके पृष्ठों की लाइव क्वेरी पर। जहां एक सटीक आंकड़े की पर्याप्त निश्चितता के साथ पुष्टि नहीं की जा सकती है, यह लेख सटीक मूल्य के बजाय परिमाण के क्रम का उपयोग करता है, और इसे स्पष्ट रूप से बताता है।

फ्रेमिंग

WASM कोल्ड स्टार्ट सर्वर रहित बहस में इतनी जगह क्यों घेरता है

कोल्ड स्टार्ट एक अनुरोध द्वारा भुगतान की गई अतिरिक्त विलंबता को संदर्भित करता है जब निष्पादन वातावरण को एप्लिकेशन कोड चलने से पहले प्रारंभ करना होगा। क्लासिक एज या सर्वर रहित फ़ंक्शन पर, यह एक सीमांत मामला होने से बहुत दूर है: एक प्लेटफ़ॉर्म जो दो ट्रैफ़िक शिखरों के बीच शून्य उदाहरणों तक जाता है, या जो भौगोलिक रूप से बिखरे हुए दर्जनों एज नोड्स में अपने निष्पादन को वितरित करता है, इस लागत का भुगतान स्थायी रूप से करता है, न कि केवल पहली तैनाती पर।

मार्च 2019 में ट्विटर पर प्रकाशित डॉकर के सह-संस्थापक सोलोमन हाइक्स के एक वाक्य के बाद से इस विषय ने WASM पारिस्थितिकी तंत्र में लगभग प्रतीकात्मक महत्व ले लिया है: "यदि WASM + WASI 2008 में अस्तित्व में था, तो हमें डॉकर बनाने की आवश्यकता नहीं होगी। यह कितना महत्वपूर्ण है। सर्वर पर WebAssembly कंप्यूटिंग का भविष्य है। » यह एक मान्यता प्राप्त व्यवसायी की राय है, माप नहीं। यह बताता है कि विषय क्यों आकर्षित करता है, यह प्रतिस्थापित नहीं करता है एक स्रोतित आंकड़ा.

ऑराबेस अपने एज फ़ंक्शंस के लिए दो पथ प्रदान करता है: स्टूडियो संपादक, जो हमारे सुपाबेस माइग्रेशन गाइडमें प्रलेखित के रूप में डेनो रनटाइम में कोड चलाता है, और aura functions deployCLI, जिसका उद्देश्य रस्ट में लिखे गए कार्यों के लिए एक अलग पथ बनाना है और वासटाइम पर WASM में संकलित करना है। यह दूसरा रास्ता है जिस पर यह लेख प्रकाश डालता है, बिना कोई ठंडी शुरुआत का आंकड़ा दिए, जो अभी तक मौजूद नहीं है।

वास्तुकला

क्यों एक WASM मॉड्यूल एक कंटेनर की तुलना में संरचनात्मक रूप से तेजी से शुरू होता है

अंतर निरपेक्ष रूप से तेज़ रनटाइम से नहीं आता है: यह क्वेरी और एप्लिकेशन कोड के बीच चरणों के छोटे ढेर से आता है।

एक कंटेनर शुरू करने से होस्ट कर्नेल जुटाया जाता है: एक नई प्रक्रिया बनाना, इसे अलग करने वाले सीग्रुप और नेमस्पेस सेट करना, छवि की परतों को माउंट करना, फिर अंदर एप्लिकेशन रनटाइम शुरू करना (नोड.जेएस और इसके वी 8 इंजन, उदाहरण के लिए, स्वयं एक आरंभीकरण लागत है)। प्रत्येक चरण सिस्टम कॉल जोड़ता है और, स्थानीय रूप से कभी नहीं देखी गई छवि के लिए, शुरू होने से पहले ही एक नेटवर्क डाउनलोड होता है।

WebAssembly मॉड्यूल को वर्चुअल मशीन भाषा स्तर पर अलग किया जाता है, ऑपरेटिंग सिस्टम स्तर पर नहीं। किसी मॉड्यूल को इंस्टेंट करने का अर्थ है इसकी रैखिक मेमोरी को आवंटित करना, इसके आयात को बाध्य करना, फिर इसके प्रवेश बिंदु पर कूदना, यह सब होस्ट रनटाइम की पहले से ही शुरू की गई प्रक्रिया के भीतर है। कोई नई प्रक्रिया नहीं, कोई छवि परतें नहीं, कोई डिफ़ॉल्ट फ़ाइल सिस्टम माउंट नहीं।

संकलन मोड का चयन एक अतिरिक्त चर जोड़ता है। जब मॉड्यूल लोड होता है तो वासटाइम अपने क्रेनलिफ्ट बैकएंड के माध्यम से जेआईटी को संकलित करता है, या इसे wasmtime compileके साथ पहले से प्रीकंपाइल कर सकता है, जो पहले से ही मूल मशीन कोड में परिवर्तित .cwasm फ़ाइल उत्पन्न करता है। प्रारंभिक संकलन (एओटी) अनुरोध के महत्वपूर्ण पथ से संकलन चरण को हटा देता है: यह बिल्कुल वह लीवर है जिसे कोल्ड स्टार्ट के प्रति संवेदनशील एज आर्किटेक्चर को सक्रिय करना होगा।

Cargo.tomltoml

# ऑराबेस भंडार से वास्तविक उद्धरण
# WASM रनटाइम
wasmtime = { version = "43", features = ["async", "cranelift"] }

यह एक उत्पादन निर्भरता है, विकास नहीं: यह पुष्टि करता है कि वास्मटाइम वास्तव में ऑराबेस एज फ़ंक्शंस के सीएलआई पथ पर चलता है। हालाँकि, यह किसी भी विलंबता आंकड़े की पुष्टि नहीं करता है, जो तब तक सत्य रहता है जब तक कोई दिनांकित बेंचमार्क प्रकाशित नहीं होता है।

आंकड़े प्रकाशित

कंटेनर और माइक्रोवीएम: सबसे सटीक मात्रात्मक संदर्भ

इस क्षेत्र में, सबसे मजबूत स्रोत एक उद्योग अनुसंधान पत्र है, न कि कोई मार्केटिंग ब्लॉग पोस्ट। फायरक्रैकर, AWS द्वारा विकसित और विशेष रूप से लैम्ब्डा और फ़ार्गेट के लिए उपयोग की जाने वाली हल्की माइक्रोवीएम तकनीक, Agache et al द्वारा USENIX NSDI 2020 सम्मेलन में प्रस्तुत की गई थी। लेख में "फायरक्रैकर: सर्वर रहित अनुप्रयोगों के लिए लाइटवेट वर्चुअलाइजेशन"।

यह पेपर एक ही भौतिक मशीन पर हजारों माइक्रोवीएम चलाने की क्षमता के साथ 125 एमएस से कम का बूट समय और 5 एमआईबी प्रति माइक्रोवीएम से कम मेमोरी ओवरहेड का दस्तावेजीकरण करता है। यह एक दिनांकित आंकड़ा (2020) है, जो एक सहकर्मी-समीक्षित अकादमिक प्रकाशन से लिया गया है, और तब से सर्वर रहित अलगाव पर साहित्य में व्यापक रूप से उद्धृत किया गया है।

एक मानक डॉकर कंटेनर आमतौर पर अधिक होता है: छवि के आकार, इसे डाउनलोड करने की आवश्यकता और एम्बेडेड एप्लिकेशन रनटाइम के बूट समय के आधार पर कुछ सौ मिलीसेकंड से लेकर कई सेकंड तक। फायरक्रैकर के विपरीत, यहां सार्वभौमिक रूप से उद्धृत कोई एकल आंकड़ा नहीं है: परिणाम आम सहमति प्राप्त करने के लिए एकल मूल्य के लिए परीक्षण की गई छवि पर बहुत अधिक निर्भर करता है।

आंकड़े प्रकाशित

वेबअसेंबली: व्हाट फास्टली, वास्मएज और अकादमिक शोध दस्तावेज़

तीन स्रोत, तीन अलग-अलग स्थितियाँ: एक ऐतिहासिक आपूर्तिकर्ता, फाउंडेशन गवर्नेंस के तहत एक परियोजना, और एक शोध पत्र।

ल्यूसेट पर 2019 में तेजी से लॉन्च किया गया Compute@Edge, इसका अपना प्री-कंपाइलिंग WASM कंपाइलर और रनटाइम है। इस लॉन्च में, कंपनी ने एक मिलीसेकंड से भी कम समय में WASM इंस्टेंटेशन समय दर्ज किया, जो परिमाण का एक क्रम था जिसका उद्योग में WASM कोल्ड स्टार्ट चर्चा पर स्थायी प्रभाव पड़ा। 2021 में, फास्टली ने ल्यूसेट के स्वायत्त विकास को बंद कर दिया और वास्मटाइम की ओर अपने प्रयासों को पुनर्निर्देशित किया, जिसके क्रेनलिफ्ट संकलन बैकएंड को इन अनुकूलन का हिस्सा विरासत में मिला: यह एक कारण है कि वास्मटाइम इस प्रकार के लोड के लिए आज भी एक संदर्भ बना हुआ है।

WasmEdge, CNCF गवर्नेंस (मूल रूप से SSVM, सेकंड स्टेट द्वारा समर्थित) के तहत एक WASM रनटाइम, अपने आधिकारिक दस्तावेज़ में किनारे और IoT लोड पर एक स्पष्ट स्थिति के साथ, समकक्ष डॉकर कंटेनर की तुलना में काफी कम स्टार्टअप और मेमोरी फ़ुटप्रिंट का दावा करता है। यह स्वयं परियोजना प्रकाशक द्वारा प्रकाशित एक आंकड़ा है, जिसे इस प्रकार पढ़ा जा सकता है: एक उत्पाद दावा, कोई स्वतंत्र ऑडिट नहीं।

अकादमिक अनुसंधान पक्ष पर, Faasm (शिलाकर और पिट्ज़ुच, USENIX ATC 2020, प्री-पब्लिकेशन में भी उपलब्ध है) वेबअसेंबली आइसोलेशन (WAVM के माध्यम से, वास्मटाइम के माध्यम से) पर भरोसा करते हुए एक स्टेटफुल सर्वरलेस प्लेटफ़ॉर्म बनाता है, क्योंकि यह किसी फ़ंक्शन को कंटेनर या VM द्वारा आइसोलेशन की तुलना में बहुत कम लागत पर तुरंत चालू करने की अनुमति देता है। पेपर विशेष रूप से वासटाइम के बारे में नहीं है, लेकिन यह पिछले अनुभाग में संरचनात्मक तर्क को स्वतंत्र अकादमिक मान्यता प्रदान करता है।

रनटाइम्स

वासटाइम बनाम वासमर बनाम वासमएज: प्रकाशित संख्याएँ पंक्तिबद्ध क्यों नहीं होतीं

केवल नाम से इन तीन रनटाइम की तुलना करने से वास्तविक चर छिप जाता है: चुना गया संकलन बैकएंड, जो स्टार्टअप गति और निष्पादन प्रदर्शन के बीच संतुलन को मौलिक रूप से बदल देता है।

वास्मटाइम	क्रेनलिफ्ट (डिफ़ॉल्ट रूप से JIT) + wasmtime संकलन के माध्यम से AOT	बाइटकोड एलायंस · ओपन गवर्नेंस, फास्टली, शॉपिफाई, ऑराबेस द्वारा उपयोग किया जाता है
वासमेर	अपनी पसंद का सिंगलपास, क्रेनलिफ्ट या एलएलवीएम	सिंगलपास संकलन समय को कम करता है; एलएलवीएम निष्पादन प्रदर्शन को अधिकतम करता है
वास्मएज	प्रोजेक्ट-विशिष्ट एओटी कंपाइलर	सीएनसीएफ · एज/आईओटी और क्लाउड-नेटिव स्थित है

सिंगलपास, वासमर का सबसे तेज़ संकलन बैकएंड, सटीक रूप से मौजूद है क्योंकि इसकी टीम ने कोल्ड स्टार्ट को स्थिर-स्थिति निष्पादन प्रदर्शन की एक विशिष्ट धुरी के रूप में पहचाना है: सिंगलपास में संकलित एक मॉड्यूल तेजी से शुरू होता है, लेकिन एलएलवीएम में संकलित समान मॉड्यूल की तुलना में पीक लोड के दौरान धीमी गति से चलता है। यह एक स्वीकृत समझौता है, कोई छिपी हुई खामी नहीं।

रनटाइम विक्रेता द्वारा प्रकाशित एक आंकड़ा एक स्वतंत्र ऑडिट नहीं है

वासमर ने वासटाइम के खिलाफ अपनी स्वयं की प्रदर्शन तुलना प्रकाशित की है, एक अभ्यास जिसने WASM समुदाय में उपयोग की जाने वाली पद्धति और परीक्षण किए गए परिदृश्यों की तुलना पर बहस छेड़ दी है। यह बुरे विश्वास का आरोप नहीं है: यह एक संरचनात्मक अनुस्मारक है। एक रनटाइम संपादक का उस परिदृश्य को प्रकाशित करने में निहित स्वार्थ होता है जहां वह जीतता है, जो किसी एकल नंबर पर आर्किटेक्चर विकल्प पर निर्णय लेने से पहले स्वतंत्र सत्यापन को और अधिक उपयोगी बनाता है।

सारांश

तुलनात्मक तालिका: प्रत्येक स्रोत क्या दस्तावेज करता है, और क्या नहीं

<125ms

बूट पटाखा

अगाचे एट अल., एनएसडीआई 2020

WASM रनटाइम्स की तुलना की गई

वासटाइम, वासमर, वासमएज

बेंचमार्क कोल्ड स्टार्ट ऑरबेस

उत्पादन में समय-समय पर जाँच की गई, कोई माप प्रकाशित नहीं हुआ

पटाखा (एडब्ल्यूएस)	<125 एमएस स्टार्टअप, <5 एमआईबी ओवरहेड सहकर्मी-समीक्षित शोध पत्र	अगाचे एट अल., यूसेनिक्स एनएसडीआई 2020
ल्यूसेट → वासटाइम (फास्टली)	मिलीसेकंड के तहत तात्कालिकता (2019) आपूर्तिकर्ता आंकड़ा, यहां पुन: प्रस्तुत नहीं किया गया है	कंप्यूट@एज, फास्टली की घोषणा
वास्मएज	छोटे स्टार्टअप और मेमोरी फ़ुटप्रिंट बनाम डॉकरपुब्लिशर उत्पाद का दावा	आधिकारिक वास्मएज दस्तावेज़ीकरण (सीएनसीएफ)
फासम (खोज)	WASM अलगाव एक कंटेनर की तुलना में तत्काल करने के लिए काफी सस्ता है, WAVM का उपयोग करता है, Wasmtime का नहीं	शिलाकर और पिट्ज़ुच, यूसेनिक्स एटीसी 2020
मानक डॉकर कंटेनर	सैकड़ों एमएस से लेकर कई सेकंड तक कोई एकल सर्वसम्मति संख्या नहीं	व्यापक रूप से प्रलेखित व्यवहार

ये पाँच पंक्तियाँ एक एकल वर्गीकरण के रूप में नहीं पढ़ी जाती हैं: वे विभिन्न पद्धतियों, तिथियों और रनटाइम पीढ़ियों से आती हैं। इस प्रकार के WASM बेंचमार्क की विश्वसनीयता की अधिक गहन पद्धतिगत आलोचना के लिए, WebAssembly बेंचमार्क की सीमाओं पर हमारा लेख वर्तमान तुलना से कहीं आगे जाता है, जो प्रत्येक स्रोत द्वारा ठोस रूप से दावा किए जाने पर केंद्रित रहता है।

व्यवहारिक निहितार्थ

एज आर्किटेक्चर की पसंद के लिए यह अंतर वास्तव में क्या बदलता है

WASM का कोल्ड स्टार्ट लाभ पहले अनुरोध की विलंबता के प्रति सबसे अधिक संवेदनशील लोड पर सबसे अधिक मायने रखता है, सभी लोड पर समान रूप से नहीं।

यह विशेष रूप से बहुत अनियमित किनारे वाले ट्रैफ़िक (विस्फोट के बाद मौन) पर भार डालता है, कई अनुरोधों के बीच साझा किए गए प्रति कंटेनर के बजाय प्रति अनुरोध अलगाव पर, और एक बुनियादी ढांचे पर जो वास्तव में एक गर्म पूल को स्थायी रूप से रखने के बजाय दो चोटियों के बीच शून्य उदाहरणों तक चला जाता है। एक स्थिर और पूर्वानुमानित लोड पर, जहां उदाहरण वैसे भी गर्म रहते हैं, कोल्ड स्टार्ट गैप संरचनात्मक रूप से कम मायने रखता है।

WebAssembly कोल्ड स्टार्ट से भिन्न बाधाओं को भी बनाए रखता है: फ़ाइल सिस्टम या नेटवर्क तक पहुंच WASI के माध्यम से होती है, एक इंटरफ़ेस अभी भी रनटाइम और उनके संस्करणों के आधार पर विकसित हो रहा है, और जल्दी से शुरू करने के लिए संकलित एक मॉड्यूल (उदाहरण के लिए, वासमर पक्ष पर सिंगलपास) एक बार भारी भार के तहत स्थापित होने के बाद सबसे तेज़ नहीं होता है। कोल्ड स्टार्ट और चरम निष्पादन प्रदर्शन दो अलग-अलग अक्ष बने रहते हैं, एक ही संकलन प्रोफ़ाइल पर एक साथ शायद ही कभी इष्टतम होते हैं।

इस मानदंड पर एज आर्किटेक्चर की पसंद का मूल्यांकन करने के लिए, किसी भी आपूर्तिकर्ता से पूछने के लिए तीन ठोस प्रश्न, ऑराबेस में शामिल हैं: कौन सा सटीक रनटाइम उपयोग किया जाता है, कौन सा संकलन बैकएंड (जेआईटी या एओटी), और उन्नत कोल्ड स्टार्ट आंकड़ा एक स्वतंत्र तीसरे पक्ष द्वारा या केवल रनटाइम प्रकाशक द्वारा ही मापा जाता है।

अक्सर पूछे जाने वाले प्रश्नों

पूछे जाने वाले प्रश्न

क्या WebAssembly कोल्ड स्टार्ट अभी भी डॉकर कंटेनर से तेज़ है?+

परिमाण के क्रम में, इस आलेख में उद्धृत स्रोत इस दिशा में जाते हैं: एक क्लासिक कंटेनर के लिए सैकड़ों मिलीसेकंड से लेकर कई सेकंड की तुलना में, WASM मॉड्यूल की तात्कालिकता के लिए माइक्रोसेकंड से मिलीसेकंड तक। लेकिन इनमें से कोई भी आंकड़ा अलग-अलग तिथियों और अलग-अलग संस्करणों पर प्रौद्योगिकियों के दो परिवारों के लिए सामान्य माप प्रोटोकॉल से नहीं आता है। इसे व्यापक रूप से प्रलेखित प्रवृत्ति के रूप में माना जाना चाहिए, न कि किसी भार के लिए मान्य संख्यात्मक गारंटी के रूप में।

वासटाइम, वासमर और वासमएज अलग-अलग शुरुआती नंबरों की घोषणा क्यों करते हैं?+

क्योंकि वे उसी तरह संकलित नहीं होते हैं। वास्मटाइम क्रेनलिफ्ट को अपने डिफ़ॉल्ट बैकएंड के रूप में उपयोग करता है और वास्मटाइम संकलन के माध्यम से प्रारंभिक निर्माण (एओटी) प्रदान करता है। वासमर आपको सिंगलपास (सबसे तेज़ संकलन), क्रेनलिफ्ट या एलएलवीएम (उच्चतम रनटाइम प्रदर्शन, धीमा संकलन) के बीच चयन करने देता है। WasmEdge में अपना स्वयं का AOT कंपाइलर शामिल है, जिसे एज और IoT के लिए डिज़ाइन किया गया है। बैकएंड का चयन प्रत्येक प्रोजेक्ट द्वारा प्रकाशित आंकड़ों के बीच अंतर का एक बड़ा हिस्सा बताता है।

कोल्ड स्टार्ट के लिए एओटी (समय से पहले) संकलन वास्तव में क्या बदलता है?+

एओटी संकलन अनुरोध के महत्वपूर्ण पथ से संकलन चरण को हटा देता है: WASM मॉड्यूल आह्वान से पहले ही मशीन कोड में बदल जाता है, जो कुछ बचा है उसे लोड करना और इंस्टेंट करना है। यह Wasmtime पक्ष और WasmEdge के स्वयं के कंपाइलर पर wasmtime संकलन के पीछे का सिद्धांत है। एक JIT संकलन प्रत्येक नए कोल्ड इंस्टेंस के साथ इस लागत का एक हिस्सा चुकाता है, जब तक कि रनटाइम परिणाम को कैश न कर दे।

क्या ऑराबेस ने अपने एज WASM फ़ंक्शंस के लिए कोल्ड स्टार्ट बेंचमार्क जारी किया है?+

नहीं, ऑराबेस अपने एज फ़ंक्शंस के सीएलआई पथ के लिए उत्पादन में वास्मटाइम का उपयोग करता है, ऑरा-फ़ंक्शंस/कार्गो.टीओएमएल (संस्करण 43, एसिंक्स और क्रेनलिफ्ट फीचर्स) में सत्यापित निर्भरता, लेकिन इस बुनियादी ढांचे पर मापा गया कोई कोल्ड स्टार्ट आंकड़े आज तक प्रकाशित नहीं किए गए हैं। किसी भी भविष्य के प्रदर्शन के आंकड़ों के लिए हमारी कार्यप्रणाली प्रतिबद्धता हमारे बेंचमार्क पद्धति लेख में विस्तृत है।

WASM रनटाइम की कोल्ड स्टार्ट और सर्वर रहित पोस्टग्रेज डेटाबेस की कोल्ड स्टार्ट के बीच क्या अंतर है?+

ये ढेर की दो अलग-अलग परतें हैं। यहां वर्णित कोल्ड स्टार्ट कोड निष्पादन वातावरण, WASM रनटाइम से संबंधित है। एक निलंबित इंस्टेंस को फिर से शुरू करने या एक नया एन्क्रिप्टेड कनेक्शन स्थापित करते समय, सर्वर रहित पोस्टग्रेज डेटाबेस कनेक्शन पूल से संबंधित अपनी स्टार्टअप विलंबता जोड़ता है। सर्वर रहित पोस्टग्रेज कोल्ड स्टार्ट पर हमारा लेख विशेष रूप से इस दूसरी परत को संबोधित करता है।

क्या हम स्वयं WASM रनटाइम संपादकों द्वारा प्रकाशित कोल्ड स्टार्ट बेंचमार्क पर भरोसा कर सकते हैं?+

सावधानी से। रनटाइम के प्रकाशक द्वारा प्रकाशित एक आंकड़ा अपनी स्वयं की परीक्षण स्थितियों का वर्णन करता है, जिसे शायद ही कभी स्वतंत्र रूप से पुन: प्रस्तुत किया जाता है, और WASM समुदाय ने पहले ही रनटाइम के बीच प्रदर्शन तुलना की पद्धति पर सार्वजनिक असहमति का अनुभव किया है। WebAssembly बेंचमार्क की सीमाओं के लिए समर्पित हमारा लेख इन पद्धति संबंधी मुद्दों का अधिक गहराई से विवरण देता है।

For the database layer of this same problem, see our article on the serverless Postgres cold start.