WASM مقابل بدء تشغيل الحاوية على البارد: ما تقوله أوقات التشغيل

تم إنشاء هذا النص الإنجليزي تلقائيًا من النص الأصلي الفرنسي ولم تتم مراجعته بعد.

تمت ترجمة هذه الصفحة تلقائيًا. النسخة الإنجليزية موثوقة.

تجمع هذه المقالة ما تنشره مصادر خارجية محددة حول البداية الباردة لـ WebAssembly مقارنة بالحاويات: ورقة بحثية مقدمة في USENIX NSDI، ووثائق رسمية من Fastly، وWasmEdge، وWasmer، ومشروع بحث أكاديمي حول العزلة بدون خادم. لم يتم تضمين أي أرقام Aurabase. تعمل وظائف الحافة الخاصة بنا بشكل جيد على Wasmtime، وتم التحقق منها في المستودع، ولكن لم يتم نشر أي معيار للبدء البارد خاص بالبنية التحتية لدينا حتى الآن، وهو تمييز مفصل أدناه. للتعرف على طريقة قياس الأداء العامة المطبقة في أي مكان آخر على هذه المدونة، راجع مقالتنا الأساسية حول منهجية قياس الأداء.

الأساسيات

توثق ورقة AWS Firecracker (Agache et al., USENIX NSDI 2020) بدء تشغيل microVM في أقل من 125 مللي ثانية وحمل ذاكرة أقل من 5 MiB: المرجع الأكثر دقة في هذه المقالة.
تم توثيق أوقات إنشاء WASM بسرعة أقل من مللي ثانية لوقت تشغيل AOT Lucet (الذي تم دمج تحسيناته بعد ذلك في Wasmtime) في عام 2019. هذا رقم نشره المورد، ولم يتم إعادة إنتاجه بشكل مستقل في المصادر التي تمت الرجوع إليها هنا.
يدعي WasmEdge، وهو مشروع يخضع لإدارة CNCF، في وثائقه الرسمية أن حجم بدء التشغيل والذاكرة أقل بكثير من حاوية Docker المكافئة، دون ذكر تدابير مضادة مستقلة في هذه المقالة.
لا يتم تجميع Wasmtime وWasmer وWasmEdge بنفس الطريقة (Cranelift وSinglepass/Cranelift/LLVM من اختيارك، مترجم AOT الخاص): يفسر هذا الاختيار للواجهة الخلفية جزءًا كبيرًا من الفجوة بين أرقامهم المنشورة، وليس فقط وقت التشغيل في حد ذاته.
تستخدم Aurabase Wasmtime في الإنتاج لوظائف الحافة الخاصة بها، والتي تم التحقق منها في aura-functions/Cargo.toml، ولكن حتى الآن لا تنشر أي أرقام بداية باردة تم قياسها على البنية التحتية الخاصة بها.

مذكرة الطريقة على المصادر

يمكن التعرف على مصادر الجهات الخارجية المذكورة أدناه من خلال عنوانها ومؤلفها أو ناشرها وتاريخ نشرها. يعتمد هذا البحث على منشورات معترف بها وموثقة على نطاق واسع في نظام WebAssembly والنظام البيئي بدون خادم، وليس استعلامًا مباشرًا لصفحاتها في وقت كتابة هذا التقرير. عندما لا يمكن تأكيد الرقم الدقيق بدرجة كافية من اليقين، تستخدم هذه المقالة ترتيب الحجم بدلاً من القيمة الدقيقة، وتنص على ذلك صراحة.

تأطير

لماذا تشغل البداية الباردة لـ WASM مساحة كبيرة في الجدل الدائر حول الخوادم

تشير البداية الباردة إلى زمن الوصول الإضافي الذي يدفعه الطلب عندما يجب تهيئة بيئة التنفيذ قبل تشغيل رمز التطبيق. في حالة الحافة الكلاسيكية أو الوظيفة التي لا تحتوي على خادم، فإن هذا أبعد ما يكون عن كونه حالة هامشية: فالمنصة التي تنخفض إلى صفر مثيلات بين ذروتين من حركة المرور، أو التي توزع تنفيذها عبر العشرات من العقد الطرفية المنتشرة جغرافيًا، تدفع هذه التكلفة بشكل دائم، وليس فقط عند النشر الأول.

اكتسب الموضوع أهمية رمزية تقريبًا في نظام WASM البيئي منذ نشر جملة من Solomon Hykes، المؤسس المشارك لـ Docker، على تويتر في مارس 2019: "لو كان WASM+WASI موجودًا في عام 2008، لما كنا بحاجة إلى إنشاء Docker. هذا هو مدى أهميته. WebAssembly على الخادم هو مستقبل الحوسبة. " هذا رأي ممارس معترف به، وليس قياسًا. وهو ما يفسر سبب الموضوع يذهل، فهو لا يحل محل شخصية مصدرها.

تقدم Aurabase مسارين لوظائف الحافة الخاصة بها: محرر Studio، الذي يقوم بتشغيل التعليمات البرمجية في وقت تشغيل Deno كما هو موثق في دليل ترحيل Supabase ، وaura functions deployCLI، الذي يهدف إلى إنشاء مسار منفصل للوظائف المكتوبة في Rust والتي تم تجميعها إلى WASM على Wasmtime. وهذا هو المسار الثاني الذي يسلط هذا المقال الضوء عليه، دون أن يعطيه بداية باردة لا وجود لها بعد.

الهندسة المعمارية

لماذا تبدأ وحدة WASM من الناحية الهيكلية بشكل أسرع من الحاوية

لا يأتي الاختلاف من وقت تشغيل أسرع بالقيمة المطلقة: بل يأتي من مجموعة أقصر من الخطوات بين الاستعلام ورمز التطبيق.

يؤدي بدء الحاوية إلى تعبئة النواة المضيفة: إنشاء عملية جديدة، وإعداد مجموعات التحكم ومساحات الأسماء التي تعزلها، وتركيب طبقات الصورة، ثم بدء تشغيل التطبيق بالداخل (على سبيل المثال، لدى Node.js ومحركها V8 تكلفة تهيئة). تضيف كل خطوة مكالمات النظام، وبالنسبة للصورة التي لم يتم عرضها محليًا، يتم تنزيلها عبر الشبكة قبل أن تبدأ.

يتم عزل وحدة WebAssembly على مستوى لغة الآلة الافتراضية، وليس على مستوى نظام التشغيل. إنشاء مثيل لوحدة يعني تخصيص ذاكرتها الخطية، وربط وارداتها، ثم الانتقال إلى نقطة الإدخال الخاصة بها، كل ذلك ضمن العملية التي بدأت بالفعل في وقت تشغيل المضيف. لا توجد عمليات جديدة، ولا طبقات صور، ولا توجد عمليات تثبيت افتراضية لنظام الملفات.

يضيف اختيار وضع الترجمة متغيرًا إضافيًا. يقوم Wasmtime بالتجميع إلى JIT عبر واجهة Cranelift الخلفية الخاصة به عند تحميل الوحدة، أو يمكنه ترجمتها مسبقًا باستخدام wasmtime compile، الذي ينتج ملف .cwasm تم تحويله بالفعل إلى رمز الجهاز الأصلي. يزيل التجميع المبكر (AOT) خطوة التجميع من المسار الحرج للطلب: هذا هو بالضبط الرافعة التي يجب أن تنشطها بنية الحافة الحساسة للبدء البارد.

Cargo.tomltoml

# مقتطف فعلي من مستودع Aurabase
# وقت تشغيل WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

هذه تبعية إنتاج وليست تطوير: فهي تؤكد أن Wasmtime يعمل فعليًا على مسار CLI لوظائف حافة Aurabase. ومع ذلك، فإنه لا يؤكد أي أرقام زمن الوصول، والتي تظل صحيحة طالما لم يتم نشر أي معيار مؤرخ.

الأرقام المنشورة

الحاويات وmicroVM: المرجع الكمي الأكثر دقة

المصدر الأقوى في هذا المجال هو ورقة بحثية صناعية، وليس منشور مدونة تسويقية. تم تقديم Firecracker، وهي تقنية microVM خفيفة الوزن طورتها AWS وتستخدم بشكل خاص لـ Lambda وFargate، في مؤتمر USENIX NSDI 2020 بواسطة Agache et al. في مقالة "Firecracker: Virtual Virtualization خفيفة الوزن للتطبيقات التي لا تحتوي على خادم".

يوثق هذا البحث وقت تشغيل أقل من 125 مللي ثانية وحمل ذاكرة أقل من 5 ميجابايت لكل microVM، مع القدرة على تشغيل آلاف microVMs على نفس الجهاز الفعلي. هذا رقم مؤرخ (2020)، مصدره منشور أكاديمي خاضع لمراجعة النظراء، وتم الاستشهاد به على نطاق واسع منذ ذلك الحين في الأدبيات المتعلقة بالعزلة بدون خادم.

تكون حاوية Docker القياسية أعلى بشكل عام: من بضع مئات من المللي ثانية إلى عدة ثوانٍ اعتمادًا على حجم الصورة، والحاجة إلى تنزيلها، ووقت تشغيل التطبيق المضمن. لا يوجد رقم واحد يتم الاستشهاد به عالميًا هنا، على عكس Firecracker: تعتمد النتيجة كثيرًا على الصورة التي تم اختبارها لقيمة واحدة لتحقيق الإجماع.

الأرقام المنشورة

WebAssembly: What Fastly، WasmEdge ووثيقة البحث الأكاديمي

ثلاثة مصادر، وثلاث حالات مختلفة: مورد تاريخي، ومشروع تحت إدارة المؤسسة، وورقة بحثية.

تم إطلاق Compute@Edge بسرعة في عام 2019 على Lucet، وهو مترجم WASM الخاص بها ووقت التشغيل الخاص بها. في هذا الإطلاق، قامت الشركة بتوثيق أوقات إنشاء WASM أقل من مللي ثانية، وهو أمر من حيث الحجم كان له تأثير دائم على خطاب البداية الباردة لـ WASM في الصناعة. في عام 2021، توقفت Fastly عن التطوير المستقل لـ Lucet وأعادت توجيه جهودها نحو Wasmtime، التي ورثت الواجهة الخلفية لتجميع Cranelift الخاصة بها جزءًا من هذه التحسينات: وهذا أحد الأسباب التي تجعل Wasmtime يظل مرجعًا اليوم لهذا النوع من الأحمال.

WasmEdge، وهو وقت تشغيل WASM تحت إدارة CNCF (في الأصل SSVM، مدعوم من Second State)، يدعي في وثائقه الرسمية أن حجم بدء التشغيل والذاكرة أقل بكثير من حاوية Docker المكافئة، مع تحديد موضع واضح على الحافة وأحمال إنترنت الأشياء. هذا رقم نشره ناشر المشروع نفسه، ويجب قراءته على هذا النحو: مطالبة بالمنتج، وليس تدقيقًا مستقلاً.

من ناحية البحث الأكاديمي، تقوم Faasm (Shillaker & Pietzuch, USENIX ATC 2020، المتوفرة أيضًا في مرحلة ما قبل النشر) ببناء نظام أساسي بدون خادم يعتمد على عزل WebAssembly (عبر WAVM، وليس Wasmtime) على وجه التحديد لأنه يسمح بإنشاء مثيل للوظيفة بتكلفة أقل بكثير من العزل بواسطة الحاوية أو بواسطة VM. لا تتعلق هذه الورقة بالزمن على وجه التحديد، ولكنها توفر التحقق الأكاديمي المستقل من الحجة البنيوية في القسم السابق.

أوقات التشغيل

Wasmtime vs Wasmer vs WasmEdge: لماذا لا تتوافق الأرقام المنشورة

إن مقارنة أوقات التشغيل الثلاثة هذه بالاسم فقط يخفي المتغير الحقيقي: الواجهة الخلفية للتجميع المختارة، والتي تغير بشكل جذري التوازن بين سرعة بدء التشغيل وأداء التنفيذ.

واسمتايم	Cranelift (JIT بشكل افتراضي) + AOT عبر ترجمة Wasmtime	Bytecode Alliance · الحوكمة المفتوحة، التي تستخدمها Fastly وShopify وAurabase
واسمر	Singlepass أو Cranelift أو LLVM من اختيارك	يقلل Singlepass من وقت الترجمة؛ LLVM يزيد من أداء التنفيذ
WasmEdge	مترجم AOT خاص بالمشروع	CNCF · الحافة/إنترنت الأشياء والسحابة الأصلية

Singlepass، أسرع واجهة خلفية تجميعية لـ Wasmer، موجودة على وجه التحديد لأن فريقها حدد البداية الباردة كمحور متميز لأداء التنفيذ في الحالة المستقرة: تبدأ الوحدة التي تم تجميعها في Singlepass بشكل أسرع، ولكنها تعمل بشكل أبطأ أثناء ذروة الحمل من نفس الوحدة التي تم تجميعها في LLVM. إنها تسوية مقبولة، وليست عيبًا خفيًا.

الرقم المنشور من قبل بائع وقت التشغيل ليس تدقيقًا مستقلاً

نشرت Wasmer مقارنات الأداء الخاصة بها مع Wasmtime، وهي ممارسة أثارت مناقشات في مجتمع WASM حول المنهجية المستخدمة وقابلية مقارنة السيناريوهات التي تم اختبارها. وهذا ليس اتهاما بسوء النية: بل هو تذكير بنيوي. لدى محرر وقت التشغيل مصلحة خاصة في نشر السيناريو الذي يفوز فيه، مما يجعل التحقق المستقل أكثر فائدة قبل اتخاذ قرار بشأن اختيار البنية لرقم واحد.

ملخص

جدول المقارنة: ما يوثقه كل مصدر، وما لا يوثقه

<125 مللي ثانية

التمهيد الالعاب النارية

أغاتشي وآخرون، NSDI 2020

مقارنة أوقات تشغيل WASM

واسم تايم، واسمر، واسم إيدج

معيار البداية الباردة AURABASE

تم فحص Wasmtime في الإنتاج، ولم يتم نشر أي قياسات

المفرقعات النارية (AWS)	< 125 مللي ثانية من بدء التشغيل، < 5 ميجا بايت من الورق البحثي الخاضع لمراجعة النظراء	أغاتشي وآخرون، USENIX NSDI 2020
لوسيت → واسم تايم (فاستلي)	إنشاء مثيل تحت رقم المورد بالمللي ثانية (2019)، غير مستنسخ هنا	الإعلان عن Compute@Edge، بسرعة
WasmEdge	حجم أصغر لبدء التشغيل والذاكرة مقابل مطالبة منتج DockerPublisher	وثائق WasmEdge الرسمية (CNCF)
فاسم (بحث)	عزل WASM أرخص بكثير في إنشاء مثيل له من الحاوية التي تستخدم WAVM، وليس Wasmtime	شيلاكر وبيتزوتش، USENIX ATC 2020
حاوية دوكر القياسية	مئات من مللي ثانية إلى عدة ثواني لا يوجد رقم إجماعي واحد	السلوك الموثق على نطاق واسع

لا يمكن قراءة هذه الأسطر الخمسة كتصنيف واحد: فهي تأتي من منهجيات وتواريخ وأجيال مختلفة في وقت التشغيل. للحصول على نقد منهجي أكثر تعمقًا لموثوقية هذا النوع من معايير WASM، فإن مقالتنا حول حدود معايير WebAssembly تذهب إلى أبعد من المقارنة الحالية، والتي تظل تركز على ما يؤكده كل مصدر بشكل ملموس.

الآثار العملية

ما الذي تغيره هذه الفجوة حقًا بالنسبة لاختيار بنية الحافة

تعتمد ميزة البدء البارد لـ WASM بشكل أكبر على الأحمال الأكثر حساسية لزمن وصول الطلب الأول، وليس على جميع الأحمال بالتساوي.

إنه يؤثر بشكل خاص على حركة مرور الحافة غير المنتظمة للغاية (الاندفاعات التي يتبعها الصمت)، وعلى العزل لكل طلب بدلاً من كل حاوية مشتركة بين عدة طلبات، وعلى البنية التحتية التي تنخفض فعليًا إلى صفر مثيلات بين قمتين بدلاً من الاحتفاظ بمجموعة ساخنة بشكل دائم. في حالة التحميل المستقر والذي يمكن التنبؤ به، حيث تظل المثيلات ساخنة على أي حال، تكون فجوة البداية الباردة أقل أهمية من الناحية الهيكلية.

يحتفظ WebAssembly أيضًا بقيود مختلفة عن البداية الباردة: الوصول إلى نظام الملفات أو الشبكة يمر عبر WASI، وهي واجهة لا تزال تتطور اعتمادًا على أوقات التشغيل وإصداراتها، ووحدة يتم تجميعها للبدء بسرعة (Singlepass على جانب Wasmer، على سبيل المثال) ليست بالضرورة الأسرع بمجرد إنشائها تحت الحمل الثقيل. تظل البداية الباردة وأداء التنفيذ الذروة محورين متميزين، ونادرًا ما يكونان مثاليين في وقت واحد على نفس ملف تعريف التجميع.

لتقييم اختيار بنية الحافة وفقًا لهذا المعيار، هناك ثلاثة أسئلة ملموسة يمكن طرحها على أي مورد، وتضمنت Aurabase: ما هو وقت التشغيل الدقيق المستخدم، وما هي الواجهة الخلفية للتجميع (JIT أو AOT)، وهل تم قياس رقم البداية الباردة المتقدمة بواسطة طرف ثالث مستقل أو فقط بواسطة ناشر وقت التشغيل نفسه.

الأسئلة المتداولة

الأسئلة الشائعة

هل لا يزال التشغيل البارد لـ WebAssembly أسرع من حاوية Docker؟+

من حيث الحجم، فإن المصادر المذكورة في هذه المقالة تذهب في هذا الاتجاه: ميكروثانية إلى ميلي ثانية لإنشاء مثيل لوحدة WASM، مقارنة بمئات المللي ثانية إلى عدة ثواني للحاوية الكلاسيكية. لكن لم تأت أي من هذه الأرقام من بروتوكول قياس مشترك بين عائلتي التكنولوجيا، في تواريخ مختلفة وفي إصدارات مختلفة. أن يتم التعامل معها على أنها اتجاه موثق على نطاق واسع، وليس كضمان عددي صالح لأي حمل.

لماذا يعلن Wasmtime وWasmer وWasmEdge عن أرقام بداية مختلفة؟+

لأنهم لا يجمعون بنفس الطريقة. يستخدم Wasmtime Cranelift كواجهة خلفية افتراضية ويقدم إنشاءًا مبكرًا (AOT) عبر ترجمة Wasmtime. يتيح لك Wasmer الاختيار بين Singlepass (أسرع تجميع)، أو Cranelift أو LLVM (أعلى أداء في وقت التشغيل، وتجميع أبطأ). يتضمن WasmEdge مترجم AOT الخاص به، المصمم للحافة وإنترنت الأشياء. يفسر اختيار الواجهة الخلفية جزءًا كبيرًا من الفجوة بين الأرقام التي ينشرها كل مشروع.

ما الذي يتغير فعليًا في تجميع AOT (المسبق) بالنسبة للبداية الباردة؟+

يقوم تجميع AOT بإزالة خطوة التجميع من المسار الحرج للطلب: تم تحويل وحدة WASM بالفعل إلى رمز الجهاز قبل الاستدعاء، وكل ما تبقى هو تحميلها وإنشاء مثيل لها. هذا هو المبدأ وراء تجميع Wasmtime على جانب Wasmtime والمترجم الخاص بـ WasmEdge. يدفع تجميع JIT جزءًا من هذه التكلفة مع كل مثيل بارد جديد، ما لم يقم وقت التشغيل بتخزين النتيجة مؤقتًا.

هل أصدرت Aurabase معيارًا للبدء البارد لوظائف WASM الخاصة بها؟+

لا. تستخدم Aurabase Wasmtime في الإنتاج لمسار CLI لوظائف الحافة الخاصة بها، وتم التحقق من التبعية في aura-functions/Cargo.toml (الإصدار 43، ميزات غير متزامنة ورافعة رافعة)، ولكن لم يتم نشر أرقام البداية الباردة المقاسة على هذه البنية التحتية حتى الآن. تم تفصيل التزامنا المنهجي بأي أرقام أداء مستقبلية في مقال المنهجية المرجعية الخاص بنا.

ما الفرق بين البداية الباردة لوقت تشغيل WASM وبداية قاعدة بيانات Postgres بدون خادم؟+

هاتان طبقتان مختلفتان من المكدس. البداية الباردة الموصوفة هنا تتعلق ببيئة تنفيذ التعليمات البرمجية، ووقت تشغيل WASM نفسه. تضيف قاعدة بيانات Postgres بدون خادم زمن الوصول الخاص ببدء التشغيل، والمتعلق بمجمع الاتصال، عند استئناف مثيل معلق أو إنشاء اتصال مشفر جديد. تتناول مقالتنا حول البداية الباردة لـ Postgres بدون خادم هذه الطبقة الثانية على وجه التحديد.

هل يمكننا الوثوق بمعايير البداية الباردة التي نشرها محررو وقت تشغيل WASM أنفسهم؟+

بحذر. ويصف الشكل الذي نشره ناشر وقت التشغيل ظروف الاختبار الخاصة به، ونادرًا ما يتم إعادة إنتاجه بشكل مستقل، وقد واجه مجتمع WASM بالفعل خلافات عامة حول منهجية مقارنات الأداء بين أوقات التشغيل. تتناول مقالتنا المخصصة لقيود معايير WebAssembly تفاصيل هذه المشكلات المنهجية بمزيد من التعمق.

بالنسبة لطبقة قاعدة البيانات التي تحتوي على نفس المشكلة، راجع مقالتنا حول البداية الباردة لـ Postgres بدون خادم.