Apache APISIX مقابل NGINX

وفقًا لإحصائيات W3Techs حتى يونيو 2022، يُعتبر NGINX خادم الويب الأكثر استخدامًا على مستوى العالم، حيث يحتل حصة سوقية كبيرة تبلغ 33.6%. وقد أسهم انتشاره الواسع وأداؤه المشهود في بناء مستوى عالٍ من الثقة بين المستخدمين، مما جعله معيارًا متكررًا للمقارنة.

نتائج اختبار الأداء

في الاختبارات العملية، قارنا أداء APISIX وNGINX في سيناريو بسيط، وكانت النتائج كما يلي:

• يُظهر APISIX أداءً في QPS يبلغ 58,080 على نواة معالج واحدة، متفوقًا على أداء NGINX الذي بلغ 37,154 على نفس العتاد.

• أداء APISIX يتفوق على NGINX بنسبة مذهلة تبلغ 56%.

تكوين الاختبار ونتائج اختبار الضغط

	APISIX	NGINX
QPS على نواة واحدة	58080	37151
اختبار الضغط
التكوينات الأساسية	routes:   -     uri: /hello     upstream:       nodes:         "127.0.0.1:1980": 1 #END	http {     access_log off;     server {         listen 1990;         location / {             proxy_pass http://127.0.0.1:1980;         }     } }
العتاد	CPU 1 CORE, 4GB RAM	CPU 1 CORE, 4GB RAM
معدل استخدام وحدة المعالجة المركزية	100%	100%

بيئة الاختبار:

• الجهاز المضيف: M1 Macbook Pro

• نظام التشغيل: Debian

إذا كنت مهتمًا بهذا، فإنه يستحق المحاولة لتكرار الاختبار بنفسك، حيث أن النتائج سهلة التكرار نسبيًا.

رؤى تقنية

وفقًا لمخطط بنية البرنامج الذي تم إصداره رسميًا من قبل APISIX، فإن التوقع المعقول هو أن أداء APISIX يجب أن يكون أقل من أداء NGINX. ومع ذلك، "الأحداث غير العادية غالبًا ما تشير إلى مشاكل كامنة." دعونا نستكشف بعض السيناريوهات غير الطبيعية التي قد تنشأ أثناء اختبار الضغط على NGINX.

لنذهب مباشرة إلى النقطة: نتائج أداء APISIX هي كما هو متوقع، وينطبق الشيء نفسه على NGINX. ومع ذلك، من المهم أن ندرك أن سيناريو الاختبار لـ APISIX يركز على أداء QPS في ظل اتصالات طويلة الأمد، بينما بالنسبة لـ NGINX، فإنه يركز على اتصالات قصيرة الأمد. لذلك، فإن الاختلاف في أداء QPS معقول.

تُستخدم الاتصالات طويلة الأمد عادةً في السيناريوهات التي تتطلب اتصالًا مستمرًا، مثل الدردشة في الوقت الفعلي أو نقل البيانات المستمر. من ناحية أخرى، تُستخدم الاتصالات قصيرة الأمد للاحتياجات المؤقتة للاتصال، مثل الوصول إلى صفحات الويب العادية في نمط طلب-استجابة HTTP.

فيما يلي مثال معقول لتكوين NGINX. مع هذا التكوين، ستلاحظ تحسنًا كبيرًا في أداء NGINX على نواة واحدة، حيث يتضاعف الأداء عادةً على الأقل.

لماذا يستخدم NGINX اتصالات قصيرة الأمد بشكل افتراضي؟

وُلد NGINX في عام 2004، ويُعتبر أحد المشاريع المفتوحة المصدر القديمة، حيث يقترب من علامة العقدين. لضمان استمرارية التكرار للمستخدمين وتجربة متسقة، يميل تطور ميزات NGINX إلى تفضيل التوافق الأمامي. وهذا يجعله واحدًا من خدمات الوكيل القليلة التي تستخدم بروتوكول HTTP 1.0 بشكل افتراضي. وقد استمر هذا الإعداد الافتراضي لأكثر من عقد، ويُعتقد أن NGINX من غير المرجح أن يغيره في المستقبل.

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