OpenResty الأسئلة الشائعة | هيكل الشبكة للاختبار، الميزات المتعلقة بـ SSL، DSL، أداة `ab`

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

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

لنلقِ نظرة على هذه الأسئلة الخمسة اليوم.

السؤال 1: كيفية بناء هيكل الشبكة للاختبار؟

س: هل يجب وضع العميل الذي يعمل بـ wrk على جهاز في الشبكة الخارجية أو على جهاز في نفس الشبكة المحلية (LAN) مثل الخادم؟ أي من هذين الخيارين أكثر فائدة لاختبار الأداء؟

ج: لاختبار خدمات الويب ذات الصلة، اختيار أداة الاختبار المناسبة هو مجرد بداية جيدة، وكيفية بناء هيكل الشبكة للاختبار هو أيضًا جزء أساسي من المتابعة.

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

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

الطريقة الثانية هي بناء شبكة محلية (LAN) مع جهاز توجيه مخصص وتوصيل الجهاز الذي يعمل عليه wrk بالجهاز الذي يعمل عليه الخادم.

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

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

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

السؤال 2: هل يمكن لـ test::nginx اختبار الميزات المتعلقة بـ SSL؟

س: هل من المستحيل اختبار الميزات المتعلقة بـ SSL باستخدام test::nginx؟

ج: هذا ليس صحيحًا. يمكن لـ test::nginx اختبار الميزات المتعلقة بـ SSL؛ يمكنك الرجوع إلى ssl.t. ملف حالة الاختبار هذا يختبر العملية الكاملة لشهادة SSL. أولاً، كما ترى، تستخدم حالة الاختبار كود Lua لقراءة المفاتيح العامة والخاصة للشهادة المحلية؛ ثم تقوم بإعداد الشهادة عبر واجهة برمجة تطبيقات HTTP؛ أخيرًا، تستخدم cosocket لإجراء مصافحة SSL والوصول للتحقق مما إذا كانت الشهادة صالحة.

في الواقع، ليس فقط SSL، ولكن أيضًا الميزات المضمنة في OpenResty يمكن تجاوزها باستخدام test::nginx.

عندما لا تكون متأكدًا مما إذا كان يمكن تنفيذ ميزة معينة باستخدام test::nginx، يمكنك البحث أولاً في حالات الاختبار لـ lua-nginx-module ومشاريع OpenResty مفتوحة المصدر الأخرى، ويمكنك عادةً العثور على أمثلة مقابلة. بعد كل شيء، test::nginx قابلة للعب والتغيير بشكل كبير، وهناك بعض التركيبات والحيل غير المتوقعة التي تنتظر الاكتشاف.

السؤال 3: ما هو DSL بالضبط؟

س: ما هي بالضبط DSL و test::nginx؟

ج: DSL تعني Domain Specific Language. الغرض من DSL يختلف عن لغات التطوير الشائعة. إنه ليس لحل احتياجات مجال عام ولكن لبعض المجالات. أشهر DSL هو SQL، لغة الاستعلام الهيكلية المستخدمة في مجال قواعد البيانات.

أما بالنسبة لـ test::nginx، فهو DSL تم إنشاؤه لمعالجة احتياجات اختبار NGINX و OpenResty. في الواقع، قام مؤلفو OpenResty باختراع العديد من أفكار DSL وجلبوا العديد من المحاولات والحلول الجديدة لمجتمع OpenResty. ومع ذلك، كما ذكر في المقال السابق، DSL هو سيف ذو حدين، والمعيار الرئيسي لقياس قيمة DSL هو ما إذا كان يمكن أن يجلب تحسينًا في الإنتاجية للمستخدمين النهائيين.

السؤال 4: مشكلة تثبيت test::nginx

س: بعد تنفيذ git clone، هل أحتاج إلى تشغيل الأمر التالي لتثبيت test::nginx؟

cd test-nginx
perl Makefile.PL
make
sudo make install

ج: في الواقع، هذا ليس صحيحًا. هنا يمكنك الرجوع إلى بعض المشاريع مفتوحة المصدر.

الخطوة 1: تثبيته عبر مدير الحزم

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

الخطوة 2: git clone أحدث test::nginx

git clone https://github.com/openresty/test-nginx.git test-nginx

الخطوة 3: تضمين دليل test-nginx عند استخدام أمر prove

prove -Itest-nginx/lib -r t

كما ذكرت سابقًا، أفضل أدلة لتثبيت OpenResty والمشاريع المحيطة به موجودة في CI، وليس في الوثائق. قد يكون هذا مختلفًا عن المشاريع الأخرى، وذلك بشكل رئيسي لأن OpenResty تحتفظ بنسخة خاصة أو إصدارات محددة من بعض المشاريع المحيطة بها ولأن OpenResty تعتمد بشكل كبير على CI. لذلك، يجب عليك استخدام واختبار OpenResty بنفس الطريقة التي يتم بناؤها في CI لضمان الاتساق مع النسخة الرسمية.

السؤال 5: هل أداة الاختبار ab جيدة أم لا؟

س: كيف أتذكر أن Zhang Yichun ذكر بشكل متكرر ab كأفضل أداة اختبار في مجموعات Google؟

ج: كما ذكرت في المقال، ab ليست أداة اختبار أداء جيدة من حيث الميزات وحدها لأنها لا يمكنها توليد ضغط طلبات كافي. ومع ذلك، فإن أداء برنامج الخادم قوي الآن. نستخدم ab بدلاً من wrk في test::nginx لأنه في وضع TEST_NGINX_BENCHMARK، يستخدم test::nginx إما ab أو weighttp، اعتمادًا على إصدار بروتوكول HTTP، كأداة لاختبار الأداء.

بالإضافة إلى ذلك، أتمنى أن تلاحظ أن تكنولوجيا الإنترنت تتغير بسرعة كبيرة، وكل منا يحتاج إلى تحديث معرفته ومهاراته في الوقت المناسب. على سبيل المثال، في رأيي، هذا الاختيار لـ test::nginx يحتاج الآن إلى تحديث، وقد لا يكون Zhang Yichun على علم بوجود wrk في ذلك الوقت. بالطبع، ربما ستكون هناك أدوات اختبار أداء أفضل من wrk في الوقت المناسب، ويجب علينا بشكل طبيعي أن نكون لدينا عقلية إيجابية ومنفتحة للتعلم والاختيار.

اليوم، أجبت بشكل رئيسي على الأسئلة المذكورة أعلاه. آمل من خلال التواصل والرد على الأسئلة أن أساعدكم في تحويل ما تتعلمونه إلى ما تحصلون عليه. أنتم أيضًا مرحب بكم في مشاركة هذه المقالة حتى نتمكن من التواصل والتقدم معًا.