اختبار الضغط

أي العوامل تؤثر على نتائج اختبار الضغط؟

• تأثير تأخير الشبكة بين آلة الضغط والخادم (يُوصى بإجراء الاختبارات داخل الشبكة الداخلية أو على الجهاز المحلي)
• تأثير عرض النطاق الترددي بين آلة الضغط والخادم (يُوصى بإجراء الاختبارات داخل الشبكة الداخلية أو على الجهاز المحلي)
• هل تم تشغيل HTTP keep-alive (يُوصى بتشغيله)
• هل العدد المتزامن كافٍ (يُفضل زيادة العدد المتزامن عند إجراء الاختبارات عبر الإنترنت)
• هل عدد العمليات في الخادم مناسب (يُوصى بأن يكون عدد عمليات الخادم لخدمة hello world متساوياً لعدد وحدات المعالجة المركزية (CPU)، ويُوصى بأن يكون ضعف عدد وحدات المعالجة المركزية (CPU) أو أكثر لخدمة القواعد البيانات)
• أداء الخدمة نفسها (على سبيل المثال، ما إذا كنت تستخدم قاعدة بيانات خارجية)

ما هو HTTP keep-alive؟

آلية الـHTTP Keep-Alive هي تقنية تُستخدم لإرسال عدة طلبات واستجابات HTTP على اتصال TCP واحد. إنّها تؤثر بشكل كبير على نتائج اختبار الأداء؛ حيث يمكن أن يؤدي إيقاف تشغيل keep-alive إلى تقليص كبير في عدد الطلبات في الالتقاط في الثانية.
حالياً، يكون تشغيل Keep-Alive هو الافتراضي في المتصفح، وهو يعني أن المتصفح سيحتفظ بالاتصالات ولن يغلقها بعد زيارة عنوان URL ما، وسيستخدمها في الطلب التالي.
نوصي بتشغيل Keep-Alive خلال اختبار الضغط.

كيفية تشغيل HTTP keep-alive أثناء اختبار الضغط؟

إذا كنت تستخدم برنامج ab لاختبار الضغط، يتطلب ذلك استخدام المعلمة -k، على سبيل المثال ab -n100000 -c200 -k http://127.0.0.1:8787/.
ويحتاج برنامج apipost إلى إرجاع رأس gzip لتمكين keep-alive (هناك خلل في apipost، انظر أدناه).
عادة، يكون تشغيل keep-alive هو الافتراضي في برامج اختبار الضغط الأخرى.

لماذا يكون QPS منخفض جدًا أثناء اختبار الضغط عبر الإنترنت؟

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

لماذا تنخفض الأداء بعد استخدام nginx بوساطة الخادم؟

يُستغرق تشغيل nginx استهلاك موارد النظام. وفي نفس الوقت، يتطلب التواصل بين nginx و webman أيضًا استهلاك موارد معين. نظرًا لأن موارد النظام محدودة، فإن عدم قدرة webman على الحصول على جميع موارد النظام يمكن أن يؤدي إلى انخفاض الأداء الكلي.
للحد من تأثير استخدام nginx بوساطة على الأداء، يمكن النظر في إيقاف سجلات nginx (access_log off;)، وتشغيل keep-alive بين nginx و webman، انظر استبانة nginx.

علاوة على ذلك، يستهلك HTTPS المزيد من الموارد مقارنة بـ HTTP، لأنه يتطلب إجراء مصافحة SSL/TLS وتشفير وفك تشفير البيانات، ويؤدي إلى زيادة حجم الحزم واستهلاك أكثر لعرض النطاق الترددي، مما يؤدي إلى انخفاض الأداء. إذا تم اختبار HTTPS بدون تشغيل keep-alive (استخدام اتصالات قصيرة)، فإن كل طلب يتطلب مصافحة SSL/TLS إضافية، مما يؤدي إلى انخفاض كبير في الأداء. يُوصى بتشغيل keep-alive خلال اختبار الأداء للـ HTTPS.

كيف يمكن معرفة أن النظام قد وصل إلى الحد الأقصى للأداء؟

بشكل عام، عند وصول الوحدة المركزية إلى 100٪، يُفهم أن أداء النظام قد وصل إلى الحد الأقصى. إذا كان هناك مساحة فارغة في وحدة المعالجة المركزية، فهذا يعني أن الحد الأقصى لم يتم بعد، وفي هذه الحالة يمكن زيادة العدد المتزامن لزيادة QPS بشكل مناسب. إذا كانت زيادة العدد المتزامن لا تؤدي إلى زيادة في QPS، فقد يكون عدد عمليات webman غير كاف، يُرجى زيادة عدد عمليات webman. إذا لم يكن ذلك كافيًا، فربما يجب التأكد من كفاية العرض الترددي.

لماذا نتائج اختبار الأداء تظهر أن أداء webman أقل من أداء إطار عمل gin الخاص بلغة go؟

يُظهر اختبار techempower أن أداء webman في جميع المؤشرات، بما في ذلك النص النقي واستعلامات قواعد البيانات وتحديثات قواعد البيانات وغيرها، أفضل بشكل عام من أداء gin بمقدار حوالي الضعف.
إذا كانت نتائج اختبارك مُختلفة، فمن الممكن أنك قد استخدمت ORM في webman مما أدى إلى انخفاض أداء ويمكنك أن تقوم بمقارنة webman + PDO الأصلي و gin + الـSQL الأصلي.

كم قد يؤدي استخدام ORM في webman إلى انخفاض الأداء؟

إليك مجموعة بيانات اختبارية
البيئة
سيرفر في السحابة: 4 وحدات معالجة مركزية و4 جيجابايت، استعلام عشوائي لإرجاع بيانات JSON من بيانات 100 ألف سجل.

إذا تم استخدام PDO الأصلي
فإن QPS ل webman هو 1.78 ألف

إذا تم استخدام laravel's Db::table()
فإن QPS ل webman ينخفض إلى 0.94 ألف QPS

إذا تم استخدام laravel's Model
فإن QPS ل webman ينخفض إلى 0.72 ألف QPS

ثينك ORM تعطي نتائج مماثلة، دون فارق كبير.

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

لماذا يكون QPS منخفضًا جدًا عند استخدام apipost لاختبار الضغط؟

موديول اختبار الضغط في apipost به خطأ، إذا لم يُعاد الخادم رأس gzip، فلن يكون بإمكانه الاحتفاظ بالkeep-alive وسيؤدي ذلك إلى انخفاض كبير في الأداء.
الحل هو ضغط البيانات وإضافة رأس gzip عند الإرجاع، على سبيل المثال

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

بالإضافة إلى ذلك، قد لا يكون apipost قادرًا في بعض الحالات على تحقيق الضغط المطلوب؛ مما يظهر أن لديه أداءًا أدنى بحوالي 50٪ من ab (أداة اختبار ضغط أخرى). يُوصى بإجراء اختبارات الضغط باستخدام ab أو wrk وغيرها من برامج اختبار الضغط المتخصصة بدلاً من apipost.

إعداد عدد مناسب للعمليات

يفتح webman الافتراضي cpu*4 عملية. في الواقع، استنادًا إلى الوظائف التي لا تمتلك تدفق إدخال/إخراج شبكي (non-IO bound) مثل خدمة helloworld، يعتبر أفضل أداء هو إدراج عدد العمليات بنفس عدد وحدات المعالجة المركزية (CPU)، لأنه يمكن تقليل تكلفة تغير العملية. إذا كان لديك خدمة مع عناصر مانعة للإفراج عن القفل الخاصة بقاعدة بيانات أو Redis، يمكن تعيين عدد العمليات بين 3-8 مرات عدد وحدات المعالجة المركزية (CPU)، لأنه في هذه الحالة يتعين زيادة عدد العمليات لزيادة التزامن، وتكاد تكون تكلفة تغير العمليات لا تذكر بالنسبة لإلحاق القفل.

بعض النطاقات المرجعية لاختبار الضغط

بيانات اختبار الضغط لطرف ثالث techempower

أمثلة على أوامر اختبار الضغط

ab

# 100000 طلب 200 متزامن تشغيل keep-alive
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 طلب 200 متزامن تفعيل keep-alive
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

#