تحدثنا عن المنهجية في في هذه المقالة، نقوم باختبار HTTPS، ولكن في سيناريوهات أكثر واقعية. للاختبار، حصلنا على شهادة Let's Encrypt وقمنا بتمكين ضغط Brotli إلى 11.
سنحاول هذه المرة إعادة إنتاج سيناريو نشر خادم على VDS أو كجهاز افتراضي على مضيف بمعالج قياسي. ولهذا الغرض تم وضع الحد عند:
- 25% - وهو ما يعادل تردد ~ 1350 ميجا هرتز
- 35%-1890 ميجا هرتز
- 41% - 2214 ميجا هرتز
- 65% - 3510 ميجا هرتز
تم تخفيض عدد الاتصالات لمرة واحدة من 500 إلى 1 و3 و5 و7 و9،
النتائج:
التأخير:
تم تضمين TTFB على وجه التحديد كاختبار منفصل، لأن أدوات HTTPD تنشئ مستخدمًا جديدًا لكل طلب فردي. لا يزال هذا الاختبار منفصلاً تمامًا عن الواقع، لأن المستخدم سيظل ينقر على بضع صفحات، وفي الواقع سيلعب TTFP الدور الرئيسي.
الأول، عادةً ما يستغرق الطلب الأول بعد التشغيل الأول لجهاز IIS الظاهري 120 مللي ثانية في المتوسط.
تُظهر كافة الطلبات اللاحقة TTFP يبلغ 1.5 مللي ثانية. Apache و Nginx متخلفان في هذا الصدد. شخصيًا، يعتبر المؤلف هذا الاختبار هو الأكثر كشفًا وسيختار الفائز بناءً عليه فقط.
والنتيجة ليست مفاجئة نظرًا لأن IIS يقوم بتخزين محتوى ثابت مضغوط بالفعل ولا يقوم بضغطه في كل مرة يتم الوصول إليه.
الوقت المستغرق لكل عميل
لتقييم الأداء، يكفي إجراء اختبار باستخدام اتصال واحد.
على سبيل المثال، أكمل IIS اختبارًا لـ 5000 مستخدم في 40 ثانية، وهو 123 طلبًا في الثانية.
توضح الرسوم البيانية أدناه الوقت حتى يتم نقل محتوى الموقع بالكامل. هذه هي نسبة الطلبات المكتملة في وقت معين. في حالتنا، تمت معالجة 80% من جميع الطلبات في 8 مللي ثانية على IIS وفي 4.5 مللي ثانية على Apache وNginx، وتم إكمال 8% من جميع الطلبات على Apache وNginx خلال فترة زمنية تصل إلى 98 مللي ثانية.
الوقت الذي تمت خلاله معالجة 5000 طلب:
الوقت الذي تمت خلاله معالجة 5000 طلب:
إذا كان لديك جهاز افتراضي مزود بوحدة معالجة مركزية بسرعة 3.5 جيجا هرتز و8 مراكز، فاختر ما تريد. جميع خوادم الويب متشابهة جدًا في هذا الاختبار. سنتحدث عن خادم الويب الذي يجب اختياره لكل مضيف أدناه.
عندما يتعلق الأمر بموقف أكثر واقعية قليلاً، فإن جميع خوادم الويب تتنافس.
الإنتاجية:
رسم بياني للتأخيرات مقابل عدد الاتصالات المتزامنة. أكثر سلاسة وأقل هو الأفضل. تمت إزالة نسبة 2% الأخيرة من المخططات لأنها تجعلها غير قابلة للقراءة.
الآن دعونا نفكر في خيار استضافة الخادم على استضافة افتراضية. لنأخذ 4 نوى بتردد 2.2 جيجا هرتز ونواة واحدة بتردد 1.8 جيجا هرتز.
كيفية القياس
إذا سبق لك أن رأيت كيف تبدو خصائص الجهد الحالي للصمامات الثلاثية الفراغية والخماسية وما إلى ذلك، فستكون هذه الرسوم البيانية مألوفة لك. وهذا ما نحاول التقاطه - التشبع. الحد الأقصى هو أنه بغض النظر عن عدد النوى التي ترميها، فإن زيادة الأداء لن تكون ملحوظة.
في السابق، كان التحدي بأكمله يتمثل في معالجة 98% من الطلبات بأقل زمن استجابة لجميع الطلبات، مع الحفاظ على المنحنى مسطحًا قدر الإمكان. الآن، من خلال إنشاء منحنى آخر، سنجد نقطة التشغيل الأمثل لكل خادم.
للقيام بذلك، لنأخذ مؤشر الطلبات في الثانية (RPR). الأفقي هو التردد، والعمودي هو عدد الطلبات التي تتم معالجتها في الثانية، والخطوط هي عدد النوى.
يُظهر ارتباطًا بمدى جودة معالجة Nginx لطلبات واحدة تلو الأخرى. 8 نوى تؤدي أداءً أفضل في هذا الاختبار.
يوضح هذا الرسم البياني بوضوح مدى جودة عمل Nginx (ليس كثيرًا) على نواة واحدة. إذا كان لديك Nginx، فيجب أن تفكر في تقليل عدد النوى إلى مركز واحد إذا كنت تستضيف النوى الثابتة فقط.
على الرغم من أن IIS لديه أدنى TTFB وفقًا لـ DevTools في Chrome، إلا أنه تمكن من الخسارة أمام Nginx وApache في معركة جادة مع اختبار التحمل من مؤسسة Apache.
كل انحناءات الرسوم البيانية مستنسخة بالحديد.
نوع من الاستنتاج:
نعم، يعمل Apache بشكل أسوأ على 1 و8 مراكز، ولكنه يعمل بشكل أفضل قليلاً على 4.
نعم، تتطلب عمليات Nginx ذات 8 مراكز أفضل واحدة تلو الأخرى، على 1 و4 مراكز، وتعمل بشكل أسوأ عندما يكون هناك العديد من الاتصالات.
نعم، يفضل IIS 4 مراكز مركزية لأحمال العمل ذات الخيوط المتعددة ويفضل 8 مراكز مركزية لأحمال العمل ذات الخيوط الواحدة. في نهاية المطاف، كان IIS أسرع قليلاً من أي شخص آخر في 8 نوى تحت الحمل العالي، على الرغم من أن جميع الخوادم كانت على قدم المساواة.
هذا ليس خطأ في القياس، الخطأ هنا لا يزيد عن +-1 مللي ثانية. في حالات التأخير وما لا يزيد عن +- 2-3 طلبات في الثانية لـ RPR.
النتائج التي يكون فيها أداء 8 مراكز أسوأ ليست مفاجئة على الإطلاق، فالعديد من النوى وSMT/Hyperthreading يؤدي إلى انخفاض الأداء بشكل كبير إذا كان لدينا إطار زمني يتعين علينا فيه إكمال المسار بأكمله.
المصدر: www.habr.com