اختبار الضغط

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

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

ما هو HTTP keep-alive؟

آلية HTTP Keep-Alive هي تقنية تستخدم لإرسال عدة طلبات واستجابات HTTP عبر اتصال TCP واحد، ولها تأثير كبير على نتائج اختبارات الأداء، قد يتضاعف QPS عند إيقاف keep-alive.
حاليًا، المتصفحات مفعل فيها keep-alive بشكل افتراضي، مما يعني أن المتصفح يحتفظ بالاتصال مؤقتًا بعد زيارة عنوان HTTP معين ولا يغلقه، ويستخدم هذا الاتصال في الطلب التالي لتحسين الأداء.
يُنصح بتفعيل keep-alive أثناء اختبار الضغط.
علاوة على ذلك، إذا تم إجراء اختبار الضغط دون تفعيل keep-alive، ستنفد المنافذ المحلية على العميل بسرعة بسبب حالة timewait، مما يظهر كعدد الطلبات الإجمالية التي تتجاوز عددًا معينًا (حوالي 28,000 عادةً) مما يؤدي إلى طلبات فاشلة.

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

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

لماذا يكون QPS منخفضًا جدًا عند اختبار عبر الشبكة العامة؟

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

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

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

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

كيف يمكن معرفة أن النظام قد بلغ حد الأداء؟

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

لماذا نتائج اختبار الضغط لدي تشير إلى أن أداء webman أقل من إطار gin الخاص بـ go؟

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

ما مقدار فقدان الأداء عند استخدام ORM في webman؟

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

البيئة
خادم على Alibaba Cloud بذاكرة 4 أنوية 4G، قاعدة بيانات MySQL محلية، استعلام عشوائي عن سجل من 100,000 سجل مع رد JSON، اختبار على الجهاز المحلي.

إذا تم استخدام PDO الأصلي
كان QPS لـ webman هو 17,800

إذا تم استخدام Db::table() في laravel
انخفض QPS لـ webman إلى 9,400

إذا تم استخدام Model في laravel
انخفض QPS لـ webman إلى 7,200

نتائج thinkORM مشابهة، الاختلاف ليس كبيرًا.

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

لماذا تكون 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 من إعطاء ضغط مرضٍ، مما يظهر كاحتمالية استخدام نفس مستوى الاتصالات المتزامنة، حيث يظهر أن apipost أقل بحوالي 50% من QPS مقارنةً بـ ab.
يُنصح باستخدام ab، wrk، أو برامج اختبار الضغط المتخصصة الأخرى بدلاً من apipost.

ضبط عدد العمليات بشكل مناسب

يتم تشغيل webman بشكل افتراضي مع عدد عمليات تساوي cpu*4. في الواقع، لمؤسسة hello world التي لا تحتوي على IO للشبكة، يكون عدد العمليات متساويًا مع عدد وحدات CPU لتحقيق أقصى أداء، لأنه يقلل من تكاليف تبديل العمليات.
إذا كانت هناك بيانات، redis، أو غيرها من الأعمال المعيقة، يمكن ضبط عدد العمليات ليكون من 3 إلى 8 أضعاف عدد وحدات CPU، حيث يتطلب هذا المزيد من العمليات لزيادة الاتصالات المتزامنة، بينما يمكن اعتبار تكاليف تبديل العمليات لا تذكر مقارنة مع IO المعيق.

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

خادم سحابي 4 أنوية 4G 16 عملية اختبار محلي/في الشبكة الداخلية

-	مع تفعيل keep-alive	بدون تفعيل keep-alive
hello world	80,000 - 160,000 QPS	10,000 - 30,000 QPS
استعلام قاعدة بيانات فردي	10,000 - 20,000 QPS	10,000 QPS

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

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

# 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

# 200 اتصالات متزامنة للاختبار لمدة 10 ثوان مع تفعيل keep-alive (افتراضي)
wrk -c 200 -d 10s http://example.com