دهش جميع موظفي ياندكس الجدد تقريبًا من حجم الضغوط التي تواجهها منتجاتنا. الآلاف من المضيفين مع مئات الآلاف من الطلبات في الثانية. وهذه ليست سوى واحدة من الخدمات. في الوقت نفسه ، يجب أن نرد على الطلبات في جزء من الثانية. حتى التغيير الطفيف في المنتج يمكن أن يكون له تأثير كبير على الأداء ، لذلك من المهم اختبار وتقييم تأثير الرمز الخاص بك على الخدمة.
في خدمتنا لتقنيات الإعلان ، يعمل الاختبار في إطار منهجية التكامل المستمر ، والتي سنناقشها بمزيد من التفصيل حول تنظيم يوم 25 أكتوبر في حدث Yandex من الداخل ، وسنشارك اليوم مع قراء Habr تجربة أتمتة تقييم مقاييس المنتج المهمة المتعلقة بأداء الخدمة. سوف تتعلم كيفية تكليف التحليل بجهاز ، وليس متابعته على الرسوم البيانية. دعنا نذهب!
لا يتعلق الأمر بكيفية اختبار الموقع. هناك العديد من الأدوات عبر الإنترنت لهذا الغرض. سنتحدث اليوم عن خدمة خلفية داخلية محملة للغاية ، والتي تعد جزءًا من نظام كبير وتعد المعلومات لخدمة خارجية. في حالتنا ، لصفحات نتائج البحث ومواقع الشركاء. إذا لم يكن لدى مكوننا الوقت للرد ، فلن يتم ببساطة إعطاء المعلومات منه للمستخدم. لذا ، ستخسر الشركة المال. لذلك ، من المهم جدا الاستجابة في الوقت المحدد.
ما هي مقاييس الخادم المهمة؟
- الطلب في الثانية (RPS) . إن سعادة مستخدم واحد ، بالطبع ، مهمة بالنسبة لنا. ولكن ماذا لو لم يكن واحدًا ، ولكن جاء الآلاف من المستخدمين إليك. كم عدد الطلبات في الثانية التي يمكن أن يتحملها الخادم الخاص بك ولا يسقط؟
- الوقت لكل طلب . يجب تقديم محتوى الموقع في أسرع وقت ممكن حتى لا يتعب المستخدم من الانتظار ، ولا يذهب إلى المتجر بحثًا عن الفشار. في حالتنا ، لن يرى جزءًا مهمًا من المعلومات على الصفحة.
- حجم المجموعة المقيمة (RSS) . تأكد من مراقبة مقدار استهلاك برنامجك للذاكرة. إذا كانت الخدمة تأكل كل الذاكرة ، فمن الصعب التحدث عن التسامح مع الخطأ.
- أخطاء HTTP .
لذا دعنا نرتبها.
طلب في الثانية
يحب المطور لدينا ، الذي يتعامل مع اختبار الحمل لفترة طويلة ، التحدث عن المورد الهام للنظام. دعنا نرى ما هو.
كل نظام له خصائص التكوين الخاصة به التي تحدد العملية. على سبيل المثال ، طول الصف ، مهلة الاستجابة ، تجمع عامل الترابط ، إلخ. ولذلك قد يحدث أن قدرة خدمتك تعتمد على أحد هذه الموارد. يمكنك إجراء تجربة. زيادة كل مورد بدوره. سيكون المورد ، الذي ستزيد زيادته من قدرة الخدمة ، أمرًا بالغ الأهمية بالنسبة لك. في النظام الذي تمت تهيئته جيدًا ، من أجل زيادة السعة ، سيتعين عليك زيادة ليس موردًا واحدًا ، بل عدة موارد. ولكن لا يزال من الممكن الشعور بهذا. سيكون من الرائع إذا كان بإمكانك تكوين نظامك بحيث تعمل جميع الموارد بكامل قوتها ، وتناسب الخدمة ضمن الأطر الزمنية المعطاة له.
لتقدير عدد الطلبات في الثانية التي سيتحملها الخادم الخاص بك ، تحتاج إلى توجيه دفق من الطلبات إليه. نظرًا لأن هذه العملية مدمجة في نظام CI ، فإننا نستخدم "مسدس" بسيط للغاية بوظائف محدودة. ولكن من برنامج مفتوح المصدر ، يعتبر Yandex.Tank مثاليًا لهذه المهمة. لديه وثائق مفصلة. الهدية إلى تانك هي خدمة لعرض النتائج.
سطح صغير. تتمتع Yandex.Tank بوظيفة غنية إلى حد ما ، ولا تقتصر على أتمتة طلبات القصف. سيساعدك أيضًا في جمع مقاييس الخدمة ، وإنشاء الرسوم البيانية ، وتثبيت الوحدة بالمنطق الذي تحتاجه. بشكل عام ، نوصي بشدة بالتعرف عليه.
تحتاج الآن إلى تغذية الطلبات إلى الخزان حتى يتمكنوا من إطلاق النار على خدمتنا. يمكن أن تكون الطلبات التي ستقسم بها الخادم من نفس النوع ، يتم إنشاؤها ونشرها بشكل مصطنع. ومع ذلك ، ستكون القياسات أكثر دقة إذا كان بإمكانك جمع مجموعة حقيقية من الطلبات من المستخدمين لفترة زمنية معينة.
يمكن قياس السعة بطريقتين.
نموذج الحمل المفتوح (اختبار الضغط)
اجعل "المستخدمين" ، أي العديد من سلاسل الرسائل التي سترسل طلبًا إلى نظامك. الحمل الذي لن نعطيه ثابتًا ، لكننا نبنيه أو حتى نطعمه في الأمواج. ثم سيقربنا من الحياة الحقيقية. نحن نزيد من RPS ونلتقط النقطة التي "تخترق فيها" الخدمة المقشرة اتفاقية مستوى الخدمة. وبالتالي ، يمكنك العثور على حدود النظام.
لحساب عدد المستخدمين ، يمكنك استخدام الصيغة الصغيرة (يمكنك القراءة عنها هنا ). مع حذف النظرية ، تبدو الصيغة كما يلي:
RPS = 1000 / T * عامل ، أين
• T - متوسط وقت معالجة الطلب (بالمللي ثانية) ؛
• العمال - عدد الخيوط.
• 1000 / T من الطلبات في الثانية - سيتم إنشاء هذه القيمة بواسطة مولد أحادي الخيوط.
نموذج الحمل المغلق (اختبار الحمل)
نأخذ عددًا ثابتًا من "المستخدمين". تحتاج إلى تكوينه بحيث يكون انسداد قائمة انتظار الإدخال المقابل لتكوين الخدمة الخاصة بك دائمًا. في الوقت نفسه ، لا معنى لجعل عدد سلاسل المحادثات أكثر من حد قائمة الانتظار ، حيث أننا سنستقر على هذا الرقم ، وسيتم تجاهل الطلبات المتبقية من قبل الخادم مع خطأ 5xx. نحن ننظر في عدد الطلبات في الثانية التي سيتمكن التصميم من إصدارها. مثل هذا المخطط في الحالة العامة ليس مشابهًا للتدفق الحقيقي للطلبات ، ولكنه سيساعد على إظهار سلوك النظام عند الحمل الأقصى وتقييم إنتاجه الحالي.
بالنسبة للغالبية العظمى من الأنظمة (حيث لا يرتبط المورد الحيوي باتصالات المعالجة) ، ستكون النتيجة هي نفسها. في الوقت نفسه ، النموذج المغلق لديه ضوضاء أقل ، لأن النظام في منطقة التحميل التي تهمنا طوال وقت الاختبار.
عند اختبار خدمتنا ، نستخدم نموذج مغلق. بعد إطلاق النار ، تعطينا البندقية عدد الطلبات في الثانية التي تمكنت خدمتنا من إصدارها. Yandex.Tank من السهل أيضًا معرفة هذا المؤشر.
الوقت لكل طلب
إذا عدنا إلى الفقرة السابقة ، يصبح من الواضح أنه مع مثل هذا المخطط ، لا معنى لتقييم وقت الاستجابة لطلب. كلما قمنا بتحميل النظام بشكل أقوى ، كلما تدهور أكثر وكلما استجاب لفترة أطول. لذلك ، لاختبار وقت الاستجابة ، يجب أن يكون النهج مختلفًا.
للحصول على متوسط وقت الاستجابة ، سنستخدم نفس Yandex.Tank. الآن فقط سنقوم بتعيين RPS الموافق لمتوسط مؤشر نظامك في الإنتاج. بعد القصف نحصل على أوقات استجابة لكل طلب. بناءً على البيانات التي تم جمعها ، يمكن حساب النسب المئوية لأوقات الاستجابة.
بعد ذلك ، تحتاج إلى فهم النسبة المئوية التي نعتبرها مهمة. على سبيل المثال ، نحن نبني على الإنتاج. يمكننا ترك 1٪ من طلبات الأخطاء ، وعدم الإجابة ، وطلبات التصحيح التي تعمل لفترة طويلة ، ومشاكل الشبكة ، وما إلى ذلك. لذلك ، نعتبر وقت الاستجابة كبيرًا ، والذي يستوعب 99٪ من الطلبات.
حجم المجموعة المقيم
يعمل خادمنا مباشرة مع الملفات من خلال mmap . من خلال قياس فهرس RSS ، نريد معرفة مقدار الذاكرة التي أخذها البرنامج من نظام التشغيل أثناء التشغيل.
في Linux ، تتم كتابة الملف / proc / PID / smaps - هذا امتداد قائم على الخريطة يوضح استهلاك الذاكرة لكل من تعيينات العملية. إذا كانت العملية الخاصة بك تستخدم tmpfs ، فسوف تدخل كل من الذاكرة المجهولة وغير المجهولة في الرسومات. تتضمن الذاكرة غير المجهولة ، على سبيل المثال ، الملفات التي يتم تحميلها في الذاكرة. هنا هو إدخال مثال في اللوحات. يتم تحديد ملف معين ، ومعلمة المعلمة الخاصة به = 0 كيلو بايت.
7fea65a60000-7fea65a61000 r--s 00000000 09:03 79169191 /place/home/.../some.yabs Size: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 4 kB Private_Dirty: 0 kB Referenced: 4 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd mr me ms
وهذا مثال لتخصيص الذاكرة المجهولة. عندما تقدم عملية (نفس mmap) طلبًا لنظام التشغيل لتخصيص حجم معين من الذاكرة ، يتم تخصيص عنوان لها. بينما تستغرق العملية ذاكرة افتراضية فقط. في هذه المرحلة ، لا نعرف حتى الآن أي جزء من الذاكرة المادية سيتم تخصيصه. نرى سجلاً بلا اسم. هذا مثال لتخصيص ذاكرة مجهولة. تم طلب النظام بحجم 24572 كيلو بايت ، لكنهم لم يستخدموه وفي الواقع تم فقط اختيار RSS = 4 كيلو بايت.
7fea67264000-7fea68a63000 rw-p 00000000 00:00 0 Size: 24572 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd wr mr mw me ac
نظرًا لأن الذاكرة المخصصة غير المجهولة لن تذهب إلى أي مكان بعد إيقاف العملية ، فلن يتم حذف الملف ، لسنا مهتمين بهذه RSS.
قبل أن تبدأ التصوير على الخادم ، نلخص RSS من / proc / PID / smaps ، المخصصة للذاكرة المجهولة ، ونتذكرها. نقوم بالقصف ، على غرار وقت الاختبار لكل طلب. بعد الانتهاء ، ضع في اعتبارك RSS مرة أخرى. سيكون الفرق بين الحالة الأولية والنهائية هو مقدار الذاكرة التي استخدمتها العملية أثناء العملية.
أخطاء HTTP
لا تنسَ اتباع رموز الاستجابة التي ترجعها الخدمة أثناء الاختبار. إذا حدث خطأ في إعداد الاختبار أو البيئة ، وأعاد الخادم أخطاء 5xx و 4 xxx لجميع طلباتك ، فليس هناك الكثير من النقاط في مثل هذا الاختبار. نحن نراقب نسبة الردود السيئة. إذا كان هناك العديد من الأخطاء ، فإن الاختبار يعتبر غير صالح.
قليلا عن دقة القياس
والآن أهم شيء. دعنا نعود إلى الفقرات السابقة. اتضح أن القيم المطلقة للمقاييس التي حسبناها ليست مهمة جدًا بالنسبة لنا. لا ، بالطبع ، يمكنك تحقيق استقرار المؤشرات ، مع مراعاة جميع العوامل والأخطاء والتقلبات. بالتوازي ، اكتب عملاً علميًا حول هذا الموضوع (بالمناسبة ، إذا كان شخص ما يبحث عن واحد ، فقد يكون هذا خيارًا جيدًا). لكن هذا ليس ما يهمنا.
من المهم بالنسبة لنا أن نؤثر على الالتزام المحدد على الكود نسبة إلى الحالة السابقة للنظام. أي أن الفرق بين المقاييس من الالتزام للالتزام مهم. وهنا من الضروري إعداد عملية تقارن هذا الاختلاف وتضمن في نفس الوقت استقرار القيمة المطلقة في هذه الفترة.
البيئة والطلبات والبيانات وحالة الخدمة - يجب إصلاح جميع العوامل المتاحة لنا. هذا النظام هو الذي يعمل بالنسبة لنا كجزء من التكامل المستمر ، حيث يزودنا بمعلومات حول جميع أنواع التغييرات التي حدثت داخل كل التزام. على الرغم من ذلك ، لن يكون من الممكن إصلاح كل شيء ، سيكون هناك ضجيج. يمكننا تقليل الضوضاء ، من الواضح ، عن طريق زيادة العينة ، أي عمل عدة تكرارات للتصوير. علاوة على ذلك ، بعد التصوير ، على سبيل المثال ، 15 تكرارًا ، يمكننا حساب متوسط العينة الناتجة. بالإضافة إلى ذلك ، من الضروري إيجاد توازن بين الضوضاء ومدة التصوير. على سبيل المثال ، استقرنا على خطأ بنسبة 1٪. إذا كنت ترغب في اختيار طريقة إحصائية أكثر تعقيدًا ودقة وفقًا لمتطلباتك ، فنحن نوصي بكتاب يسرد الخيارات مع وصف متى وأيهما يُستخدم.
ماذا يمكن عمله بالضوضاء؟
لاحظ أن البيئة التي تجري فيها الاختبارات تلعب دورًا مهمًا في مثل هذا الاختبار. يجب أن يكون منضدة الاختبار موثوقًا بها ، ولا يجب تشغيل برامج أخرى ، لأنها يمكن أن تؤدي إلى تدهور الخدمة. بالإضافة إلى ذلك ، يمكن أن تعتمد النتائج على ملف الحمولة والبيئة وقاعدة البيانات والعديد من "العواصف المغناطيسية".
كجزء من اختبار التزام واحد ، نقوم بإجراء عدة تكرارات على مضيفين مختلفين. أولاً ، إذا كنت تستخدم السحابة ، فيمكن أن يحدث أي شيء هناك. حتى إذا كانت السحابة متخصصة ، مثل خدماتنا ، فإن عمليات الخدمة لا تزال تعمل هناك. لذلك ، لا يمكنك الاعتماد على النتيجة من مضيف واحد. وإذا كان لديك مضيف حديد ، حيث لا يوجد ، كما هو الحال في السحابة ، آلية قياسية لرفع البيئة ، يمكنك حتى كسرها عن طريق الخطأ مرة واحدة وتركها بهذه الطريقة. وسوف يكذب عليك دائما. لذلك ، نحن نقود اختباراتنا في السحابة.
صحيح ، ينشأ سؤال آخر من هذا. إذا تم إجراء القياسات الخاصة بك في كل مرة على مضيفين مختلفين ، فقد تصدر النتائج القليل من الضوضاء وبسبب ذلك. ثم يمكنك تطبيع القراءات إلى المضيف. أي ، وفقًا للبيانات التاريخية ، قم بجمع "معامل المضيف" وأخذه في الاعتبار عند تحليل النتائج.
يظهر تحليل البيانات التاريخية أن الأجهزة مختلفة. تتضمن كلمة "أجهزة" هنا إصدار النواة وعواقب وقت التشغيل (على ما يبدو ، لا توجد كائنات نواة متحركة في الذاكرة).
وبالتالي ، لكل "مضيف" (عند إعادة التشغيل ، "يموت" المضيف ويظهر "جديد") نربط التصحيح الذي نضرب به RPS قبل التجميع.
نحن نعتبر ونحدث التعديلات بطريقة خرقاء للغاية ، تذكرنا بشكل مثير للريبة ببعض خيارات التدريب التعزيزي.
بالنسبة لناقلات معينة للتصحيحات اللاحقة ، فإننا نعتبر الوظيفة الموضوعية:
- في كل اختبار نعتبر الانحراف المعياري لنتائج RPS "المصححة" التي تم الحصول عليها
- خذ المتوسط منها بأوزان متساوية ،
- لدينا تاو = أسبوع واحد.
ثم نقوم بإصلاح تصحيح واحد (للمضيف الذي يكون مجموع أوزانه هو الأكبر) ، ونصلحه عند 1.0 ونبحث عن قيم جميع التصحيحات الأخرى التي تعطي الحد الأدنى من الوظيفة الهدف.
من أجل التحقق من صحة النتائج على البيانات التاريخية ، فإننا ننظر في التصحيحات على البيانات القديمة ، وننظر في النتيجة المصححة على أحدث ، مقارنة مع غير المصححة.
هناك خيار آخر لتعديل النتائج وتقليل الضوضاء وهو التطبيع إلى "المواد التركيبية". قبل بدء الخدمة المراد اختبارها ، قم بتشغيل "برنامج اصطناعي" على المضيف ، يمكنك من خلاله تقييم حالة المضيف وحساب عامل التصحيح. ولكن في حالتنا ، نستخدم التصحيحات المستندة إلى المضيف ، وظلت هذه الفكرة فكرة. ربما سيحبها أحدكم.
على الرغم من الأتمتة وجميع مزاياها ، لا تنسى ديناميكيات مؤشراتك. من المهم التأكد من أن الخدمة لا تتدهور بمرور الوقت. قد لا تلاحظ انخفاضًا طفيفًا ، وقد تتراكم ، وعلى مدى فترة زمنية طويلة ، قد تتدهور مؤشراتك. فيما يلي مثال على الرسوم البيانية التي ننظر إليها في RPS. يُظهر القيمة النسبية لكل التزام تم التحقق منه ورقمه والقدرة على معرفة المكان الذي تم تخصيص الإصدار منه.
إذا قرأت المقالة ، فسيكون من المثير للاهتمام بالتأكيد أن ترى تقريرًا عن Yandex.Tank وتحليلًا لنتائج اختبار الحمل.
نذكرك أيضًا أنه بمزيد من التفاصيل حول تنظيم التكامل المستمر ، سنتحدث عن 25 أكتوبر في حدث Yandex من الداخل . تعال للزيارة!