أنا في طريقي عائدًا من Rust Conf. في Unconf، أجرينا مناقشة مثمرة حول تصحيح أخطاء التطبيقات غير المتزامنة وقياس أدائها. تمت مشاركة العديد من الرؤى المثيرة للاهتمام. أحاول هنا تعداد بعضها، إلى جانب بعض تجاربي الخاصة. هذه هي المسودة الأولى لما آمل أن يصبح وثيقة حية لأفضل الممارسات. لا تتردد في فتح issue أو تقديم PR. آمل أيضًا إضافة تطبيق نموذجي في الأيام القادمة يوضح هذه المشكلات إلى جانب شكل dial9 trace.— Russell

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

المبادئ العامة

أولاً، حدد ما إذا كانت لديك مشكلة. إذا بدأت بالبحث عن إشارات تحذيرية في تطبيق Tokio، فستجدها. تقريبًا كل تطبيق حقيقي رأيته لديه polls أطول بكثير من 10-100 ميكروثانية التي توصي بها Alice Ryhl في مقالتها الممتازة What is Blocking?. قد تؤثر هذه المشكلات أو لا تؤثر على مقاييس التطبيق أو السلوك الذي تهتم به فعلاً. من المهم العمل بشكل عكسي من مقياس حقيقي تحاول تحسينه. على سبيل المثال، قد يكون لدى تطبيق polls طويلة حميدة تمامًا؛ "إصلاحها" لن يؤثر بشكل قابل للقياس على المقاييس الموجهة للمستخدم. في الغالبية العظمى من المشكلات التي صادفتها، كانت المشكلة في كود التطبيق نفسه، غالبًا في التفاعل بين مكونات متعددة لنظام موزع (وليس فعلاً في Tokio). لقد أعطى dial9 الكثير من الرؤية في Tokio؛ فعلى الأقل بقدر ما يجد مشكلة في Tokio، فإنه في الواقع يوضح بوضوح غيابها. بالطبع، أحيانًا تكون مشكلة في Tokio. من حيث مقاييس Tokio، الأكثر فائدة هو histogram زمن استجابة الجدولة (schedule latency) المضاف حديثًا. زمن استجابة الجدولة هو مقدار الوقت بين أن تصبح مهمتك جاهزة للتشغيل وأن يقوم Tokio فعليًا بعمل poll للـ future. على الرغم من أن هذا لن يخبرك بالسبب، فإن زمن استجابة الجدولة هو العَرَض الأكثر شيوعًا للتفاعلات السيئة بين Tokio وكودك.

قسّم من أجل زمن الاستجابة، وجمّع من أجل الإنتاجية. قم بعمل yield بشكل أكثر تكرارًا لتحسين زمن الاستجابة. يتطلب زمن الاستجابة المنخفض عبر العديد من الطلبات إنصافًا بين الاتصالات. فكر في Redis (أو أي تطبيق يدعم pipelining الطلبات). سيقوم تنفيذ ساذج بقراءة البيانات مباشرة من الاتصال طالما توفر المزيد من البيانات. عندما تكون الطلبات pipelined، سينتهي الطلب الكامل المُنفَّذ بـ pipeline في مخزن مؤقت في الذاكرة. عندما تقرأ frames منه، سيكون كل منها Poll::Ready دون العودة إلى الشبكة. وهذا يخلق كلاً من polls الطويلة وعدم الإنصاف بين العملاء. عادةً ما يكون التأثير على الإنتاجية أصغر: تتم معالجة نفس عدد الطلبات. لكن زمن الاستجابة يتغير بشكل كبير لأن pipeline كاملاً يمكن أن ينتظر خلف آخر. يمكن أن يؤدي عمل yield صراحةً بعد كل طلب إلى تقليل زمن الاستجابة بنحو 10× في هذا المثال. يمكنك فعل ما هو أفضل من ذلك بعمل yield فقط بعد عدة قراءات متتالية جاهزة فورًا.

الكيانات الرئيسية: الشركات: Tokio، Redis | الأشخاص: Russell، Alice Ryhl | المواقع: Rust Conf