عندما تواجه اختبار التحميل حدود معدل أو WAF أو توازن جغرافي، فإن الفكرة الأولى هي "سأطلق حركة المرور من عناوين IP مختلفة". يبدو منطقياً، ولكن في الممارسة العملية، تحل البروكسي في k6 و JMeter مجموعة ضيقة من المهام، ولا يزال يتعين إصلاح كل شيء آخر من خلال بنية الاختبار. في هذه المقالة، سنناقش كيفية توصيل البروكسي تقنيًا بالأداتين، وما هي أنواع IP المناسبة لذلك وأين تنتهي مسؤولية خادم البروكسي.
لماذا يحتاج اختبار التحميل إلى عناوين IP مختلفة
بشكل افتراضي، ترسل k6 و JMeter كل حركة المرور من عنوان IP واحد - الخادم الذي يتم تشغيل الاختبار عليه (أو آلة سحابية في CI/CD). هذا طبيعي لـ 90% من السيناريوهات، ولكن في بعض الحالات، يكون عنوان IP واحد غير كافٍ:
- تحديد معدل الطلب على مستوى IP. العديد من واجهات برمجة التطبيقات والموازنات (nginx limit_req، AWS WAF، Cloudflare) تحد من عدد الطلبات من عنوان واحد في الثانية. يأتي المستخدمون الحقيقيون من آلاف عناوين IP مختلفة، بينما يواجه اختبارك من عنوان واحد - ويصل إلى الحد قبل أن يصل إلى عنق الزجاجة الحقيقي للتطبيق.
- اختبار المنطق المعتمد على الجغرافيا. CDN، المحتوى المستهدف، الأسعار الإقليمية، الحظر الجغرافي - كل ذلك يحتاج إلى التحقق من عناوين IP من دول معينة، وليس من مركز البيانات حيث يوجد فعليًا عداء الاختبار الخاص بك.
- التحقق من الموازن والشبكة متعددة الإرسال. إذا كانت البنية التحتية توزع حركة المرور عبر المناطق بناءً على IP العميل، فإن الاختبار من عنوان واحد سيتحقق فقط من مسار واحد، وليس الشبكة بأكملها.
- محاكاة التوزيع الحقيقي لحركة المرور. يتم توزيع IP لحركة المرور الإنتاجية عبر مزودي الخدمة، والشبكات الفرعية، وأحيانًا عبر مشغلي الهواتف المحمولة - وهذا يؤثر على سلوك CDN، والذاكرة المؤقتة، ومنطق الحافة.
من المهم أن نفصل على الفور: إذا كنت تختبر أداء الواجهة الخلفية (كم عدد RPS الذي سيتحمله واجهة برمجة التطبيقات الخاصة بك)، فإن البروكسي نادرًا ما تكون ضرورية - فالأهم هو الحمل النقي، وليس تنوع المصادر. البروكسي ضرورية عندما يعتمد سيناريو الاختبار على عنوان IP للعميل.
ما هي أنواع البروكسي المناسبة: مركز البيانات، السكنية، المحمولة
يؤثر اختيار نوع البروكسي بشكل مباشر على ما تختبره بالضبط - سعة البنية التحتية أو سلوك النظام تحت عناوين IP "حقيقية".
| نوع البروكسي | الزمن والسرعة | متى تستخدم في اختبارات التحميل |
|---|---|---|
| بروكسي مركز البيانات | زمن منخفض، سعة عالية | التحقق من تحديد معدل الطلب، تجاوز حد "N طلبات من IP"، توليد حجم كبير من RPS من شبكات فرعية مختلفة |
| بروكسي سكنية | زمن أعلى، السرعة محدودة بقناة المستخدم الحقيقي | اختبار المنطق الجغرافي، التحقق من CDN وأنظمة مكافحة الروبوتات التي تثق في النطاقات السكنية أكثر من مركز البيانات |
| بروكسي محمولة | أعلى زمن، سرعة غير مستقرة | سيناريوهات متخصصة: اختبار واجهة برمجة التطبيقات المحمولة، السلوك عند تغيير IP بشكل متكرر (المشغلون يغيرون عنوان العميل ديناميكيًا) |
للتحقق النقي من RPS و تحديد معدل الطلب، يكفي تقريبًا استخدام بروكسي مركز البيانات - فهي توفر زمن منخفض مستقر ولا تشوه نتائج الاختبار بسبب عدم استقرار الشبكة الخارجية. تضيف البروكسي السكنية والمحمولة واقعية في الاختبارات الجغرافية، لكنها تضيف زمنها الخاص، والذي يجب أن يؤخذ في الاعتبار عند تحليل المقاييس - وإلا سيكون من السهل الخلط بين "توقف الشبكة بسبب البروكسي" و "توقف خادمك".
إعداد البروكسي في k6
k6 هو أداة مكتوبة بلغة JavaScript (المحرك مكتوب بلغة Go، والبرامج النصية مكتوبة بلغة JS)، وبشكل افتراضي لا يوجد دعم مدمج للبروكسي HTTP عبر خيارات البرنامج النصي: يتم تعيين البروكسي في k6 من خلال متغيرات البيئة أو الإعدادات النظامية، لأن k6 يستخدم عميل HTTP الخاص بـ Go تحت الغطاء.
أسهل طريقة هي استخدام متغيرات البيئة:
export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"
k6 run script.jsستوجه هذه الطريقة كل حركة المرور الخاصة بالاختبار عبر بروكسي واحد - وهي مناسبة إذا كنت بحاجة فقط للابتعاد عن عنوان IP "الأبيض" للخادم. ولكن إذا كانت المهمة هي توزيع المستخدمين الافتراضيين (VU) عبر عناوين IP مختلفة، فستحتاج إلى قائمة بالبروكسي ومنطق الاختيار على مستوى البرنامج النصي. لا يدعم k6 مباشرة البروكسي لكل VU "من الصندوق"، لذا فإن الحل الشائع هو تشغيل عدة عمليات k6 بالتوازي، كل منها مع متغير البيئة الخاص بها وبروكسيها من المجموعة:
// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")
for proxy in "${PROXIES[@]}"; do
HTTP_PROXY="http://user:pass@$proxy" \
HTTPS_PROXY="http://user:pass@$proxy" \
k6 run --vus 50 --duration 5m script.js &
done
waitهذا النهج يتوسع بشكل جيد مع k6 Cloud أو التنسيق عبر Kubernetes/Docker Compose - يتم رفع كل حاوية مع متغير البروكسي الخاص بها. إذا كنت بحاجة إلى دوران IP داخل تشغيل واحد للبرنامج النصي، فمن المنطقي أخذ البروكسي مع دوران من جانب مزود البروكسي نفسه (جلسة ثابتة مع TTL)، بدلاً من بناء دوران داخل كود JS.
إعداد البروكسي في JMeter
في JMeter، يتم إعداد البروكسي بشكل محلي، بدون متغيرات البيئة، من خلال عنصر HTTP Request Defaults أو مباشرة في إعدادات HTTP Request Sampler:
- أضف عنصر التكوين HTTP Request Defaults إلى مجموعة الخيوط.
- في حقول Proxy Server، أدخل المضيف ورقم المنفذ للبروكسي.
- إذا كان البروكسي يتطلب مصادقة - أضف عنصر HTTP Authorization Manager مع اسم المستخدم وكلمة المرور لهذا المضيف.
- ستقوم جميع HTTP Request Samplers داخل مجموعة الخيوط تلقائيًا بوراثة إعدادات البروكسي.
لتوزيع الحمل عبر عدة بروكسي في JMeter، من السهل استخدام CSV Data Set Config - يتم إدخال ملف بقائمة البروكسي في متغيرات المضيف ورقم المنفذ لكل خيط:
proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3
قم بتوصيل CSV Data Set Config بمجموعة الخيوط، وحدد المتغيرات ${proxy_host} و ${proxy_port} في حقول Proxy Server/Proxy Port للمجمع - سيأخذ كل خيط في JMeter صفه الخاص من الملف وسيستخدم IP الخاص به. لتشغيل من خلال سطر الأوامر (وضع الرأس، وهو موصى به للتجارب الحقيقية) يمكن أيضًا تمرير البروكسي كعلامات:
jmeter -n -t test_plan.jmx -l results.jtl \
-H proxy-host -P port \
-u username -a passwordهذه الطريقة تحدد بروكسي واحد مشترك للاختبار بأكمله - بالنسبة للسيناريوهات متعددة البروكسي، لا يزال يتعين استخدام CSV Data Set Config أو اختبار موزع (عدة JMeter عبيد، كل منها مع بروكسيه في التكوين).
دوران IP وتوزيع الحمل
هناك نهجان مختلفان تمامًا لتوزيع IP في اختبار التحميل:
- تثبيت ثابت لـ IP مع الخيط/VU. يحصل كل مستخدم افتراضي على نفس IP طوال الجلسة - يحاكي مستخدمًا حقيقيًا بعنوان واحد. يتم إعداده من خلال بروكسي الجلسة الثابتة أو ببساطة قائمة ثابتة في CSV/متغيرات البيئة.
- دوران IP مع كل طلب. يقوم البروكسي بتغيير العنوان الصادر مع كل طلب HTTP - مفيد للتحقق من الحماية من تحديد المعدل، ولكنه يعكس بشكل ضعيف سلوك المستخدمين الحقيقيين، الذين لا تتغير IP الخاصة بهم كل ثانية.
لاختبار تحميل واقعي، في 90% من الحالات، من الأفضل تثبيت IP مع VU/الخيط طوال الجلسة - هكذا يعكس الاختبار سلوك العديد من المستخدمين المستقلين بصدق، بدلاً من خلق ضوضاء اصطناعية. من المنطقي تضمين دوران مع كل طلب فقط في السيناريوهات الضيقة - على سبيل المثال، عند التحقق المستهدف من قواعد تحديد المعدل.
ما الذي لا يمكن للبروكسي استبداله بالتأكيد
هنا النقطة الرئيسية في المقالة: تحل البروكسي مشكلة "من أي IP يأتي الطلب"، ولكنها لا تحل المشكلات التي يتحقق منها اختبار التحميل بالفعل.
- سعة عداء الاختبار الخاص بك. إذا كانت مولد الحمل (الآلة نفسها مع k6/JMeter) تواجه CPU أو ذاكرة أو بطاقة شبكة - لن تصلح البروكسي ذلك. تضيف البروكسي قفزة شبكية إضافية وزمنها الخاص، ولا تخفف الحمل عن العدّاء.
- السعة الحقيقية للخادم الذي يتم اختباره. إما أن يتحمل الخادم الحمل أو لا - عنوان IP للعميل لا يؤثر على ذلك، باستثناء حالات تحديد المعدل الواضحة حسب IP.
- موثوقية مقاييس زمن الاستجابة. تضيف البروكسي زمنها الخاص (خاصة السكنية والمحمولة)، والذي سيدخل في تقاريرك كجزء من زمن الاستجابة. إذا لم يتم خصم زمن البروكسي بشكل منفصل، ستكون تقارير زمن الاستجابة النهائية مشوهة وغير مناسبة للمقارنة مع مقاييس الإنتاج.
- توسيع البنية التحتية لحركة المرور الحقيقية. يظهر اختبار التحميل مع البروكسي سلوكًا تحت نمط معين من الطلبات، ولكنه لا يحل تخطيط السعة، والتوسع التلقائي، وملفات الحمل المبنية على سجلات الإنتاج الحقيقية.
- التحقق من صحة منطق الأعمال تحت الحمل. حالات السباق، الأقفال في قاعدة البيانات، تدهور الطوابير - هذه هي اختبارات التنافس والتProfiling، وليس تغيير IP الصادر.
البروكسي هي أداة لمهمة خاصة "محاكاة حركة المرور من عناوين IP مختلفة"، وليست معززًا عالميًا لاختبار التحميل. إذا كانت الهدف هو فهم كم عدد RPS التي سيتحملها الواجهة الخلفية، فإن البروكسي في معظم الحالات ليست ضرورية على الإطلاق: يكفي عدد قليل من العدائين الاختباريين بدون بروكسي، مع إعداد صحيح لـ keep-alive ومجموعة اتصالات.
الأخطاء الشائعة عند الاختبار عبر البروكسي
في الممارسة العملية، تتلخص معظم المشكلات مع البروكسي في اختبارات التحميل في عدد قليل من الأخطاء المتكررة.
- خلط زمن البروكسي مع زمن الخدمة التي يتم اختبارها. بدون قياس خط الأساس (طلب مباشر بدون بروكسي) من المستحيل فهم عدد المللي ثانية التي يضيفها خادم البروكسي نفسه.
- استخدام بروكسي محمولة أو سكنية حيث تحتاج إلى سعة نقية. هذه البروكسي محدودة بقناة الجهاز النهائي الحقيقي ولا يمكنها تحمل عشرات الآلاف من RPS - تحتاج إلى بروكسي مركز البيانات للحمل النقي.
- مجموعة غير كافية من IP لعدد كبير من VU. إذا كان هناك 10 عناوين بروكسي لكل 5000 مستخدم افتراضي، سيواجه الاختبار نفس تحديد المعدل، ولكن مع زمن - سيرى الخدمة بسرعة نمط "10 IP، آلاف الطلبات".
- تجاهل المهلات على جانب البروكسي. عند الحمل التنافسي العالي، قد يبدأ خادم البروكسي في رفض الاتصالات - من المهم التحقق مسبقًا من حدود الجلسات المتزامنة مع مزود البروكسي.
- تشغيل الاختبار بدون التحقق من whitelisting/المصادقة. إذا كان البروكسي يتطلب مصادقة حسب IP، وكان الاختبار يتم تشغيله من CI/CD بعنوان ديناميكي للعداء - ستفشل الطلبات مع 407 Proxy Authentication Required، وستكون نتائج الاختبار بلا معنى.
قائمة التحقق قبل بدء الاختبار
- تحديد ما إذا كانت المهمة تتطلب حقًا عناوين IP مختلفة، أو إذا كان يكفي اختبار من عنوان واحد.
- اختيار نوع البروكسي المناسب للمهمة: مركز البيانات لـ RPS و تحديد المعدل، السكنية/المحمولة للمنطق الجغرافي.
- إجراء قياس خط الأساس بدون بروكسي، لفصل زمن الشبكة عن زمن البروكسي.
- التحقق من حدود الاتصالات المتزامنة مع مزود البروكسي لمستوى VU المطلوب.
- إعداد مصادقة البروكسي (اسم المستخدم/كلمة المرور أو whitelisting IP للعداء).
- تحديد ما إذا كانت جلسة ثابتة مطلوبة لـ VU أو دوران مع كل طلب.
- تشغيل الاختبار على فترة قصيرة (1-2 دقيقة) قبل التشغيل الكامل، للتحقق من التكوين.
الخاتمة
البروكسي في k6 و JMeter هي وسيلة فعالة لمحاكاة حركة المرور من عناوين IP مختلفة، والتحقق من سلوك تحديد المعدل والمنطق المعتمد على الجغرافيا. لكنها ليست بديلاً عن التخطيط الجيد لاختبار التحميل: لا تتحقق البروكسي من سعة الخادم، أو استقرار الواجهة الخلفية تحت الحمل التنافسي، أو التخطيط الفعلي للسعة. استخدمها بشكل دقيق - حيث يعتمد الاختبار حقًا على عنوان IP للعميل، وليس كأداة عالمية "لتحقيق العدالة".
إذا كانت المهمة هي اختبار الحدود حسب IP ومحاكاة حركة مرور جماعية بسعة عالية، فمن المنطقي البدء بـ بروكسي مركز البيانات - فهي توفر أقل زمن وتتحمل عددًا كبيرًا من الجلسات المتزامنة. للاختبارات المرتبطة بالمنطق الجغرافي وثقة أنظمة مكافحة الروبوتات في مصدر الحركة، ستكون البروكسي السكنية أفضل، وللسيناريوهات المتخصصة مع حركة المرور المحمولة - عناوين IP المحمولة.