DEV Community

Cover image for اختبار تحميل فيجيتا: دليل HTTP بمعدل ثابت
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

اختبار تحميل فيجيتا: دليل HTTP بمعدل ثابت

أنت تريد قياس سلوك واجهة برمجة التطبيقات (API) عند 500 طلب في الثانية بالضبط، وليس عند “أقصى سرعة تستطيع الخيوط تنفيذها”. معظم أدوات اختبار التحميل تثبّت عدد المستخدمين أو الخيوط وتترك معدل الطلبات يتغير. Vegeta يفعل العكس: تحدد معدل الطلبات، وهو يحافظ عليه بغض النظر عن سرعة استجابة الخادم. هذا مهم عندما تريد قياس الإنتاجية، وزمن الاستجابة، وحدود السعة عند حمل معروف يمكن استخدامه في SLO أو قرارات البنية التحتية.

جرّب Apidog اليوم

ما هو Vegeta

Vegeta هي أداة اختبار تحميل HTTP من سطر الأوامر، مكتوبة بلغة Go. يمكن استخدامها كمكتبة Go أيضًا، لكن هذا الدليل يركز على CLI.

الفكرة الأساسية بسيطة:

أرسل N طلب في الثانية لمدة محددة
Enter fullscreen mode Exit fullscreen mode

مثال:

أرسل 100 طلب/ثانية لمدة 30 ثانية
Enter fullscreen mode Exit fullscreen mode

ستحاول Vegeta الحفاظ على هذا المعدل بإضافة عمال حسب الحاجة. إذا تباطأ الخادم، تستمر الأداة في إرسال طلبات جديدة في وقتها بدل انتظار انتهاء الطلبات القديمة.

هذا يجعلها مناسبة لاختبار نموذج تحميل مفتوح، حيث تصل الطلبات حسب معدل محدد كما يحدث غالبًا في الإنتاج.

التحميل القائم على المعدل مقابل التحميل القائم على التزامن

الفارق العملي كالتالي:

النموذج كيف يعمل ماذا يحدث عند بطء الخادم؟
قائم على التزامن عدد ثابت من المستخدمين أو الخيوط يكررون الطلبات ينخفض معدل الطلبات تلقائيًا لأن كل عامل ينتظر الاستجابة
قائم على المعدل معدل وصول ثابت مثل 500 RPS تستمر الطلبات في الوصول، فيظهر التكدس وزمن الاستجابة الحقيقي

الأدوات القائمة على التزامن تجيب عن سؤال:

كم عدد المستخدمين المتزامنين الذين يمكنني دعمهم؟

أما Vegeta فتجيب عن سؤال:

ماذا يحدث عند 2,000 طلب في الثانية؟

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

تثبيت Vegeta

اختر طريقة التثبيت المناسبة لنظامك.

على macOS باستخدام Homebrew:

brew update && brew install vegeta
Enter fullscreen mode Exit fullscreen mode

مدراء حزم آخرون:

# MacPorts
port install vegeta

# Arch Linux
pacman -S vegeta

# FreeBSD
pkg install vegeta
Enter fullscreen mode Exit fullscreen mode

من المصدر إذا كان Go مثبتًا:

git clone https://github.com/tsenart/vegeta
cd vegeta
make vegeta
Enter fullscreen mode Exit fullscreen mode

يمكنك أيضًا تنزيل ملف ثنائي جاهز من صفحة إصدارات GitHub.

تحقق من التثبيت:

vegeta --help
Enter fullscreen mode Exit fullscreen mode

أول اختبار تحميل باستخدام Vegeta

تعمل Vegeta جيدًا مع أنابيب Unix. أبسط اختبار مفيد:

echo "GET http://localhost:8080/" | vegeta attack -duration=5s -rate=100 | vegeta report
Enter fullscreen mode Exit fullscreen mode

ما يحدث هنا:

  1. echo يرسل هدفًا واحدًا: طريقة HTTP وعنوان URL.
  2. vegeta attack يرسل 100 طلب في الثانية لمدة 5 ثوانٍ.
  3. vegeta report يقرأ النتائج ويطبع الملخص.

إجمالي الطلبات المتوقع:

100 طلب/ثانية × 5 ثوانٍ = 500 طلب
Enter fullscreen mode Exit fullscreen mode

يمكنك كتابة المعدل بعدة صيغ:

-rate=100       # 100 طلب في الثانية
-rate=100/1s    # نفس المعنى
-rate=50/500ms  # 50 طلب كل 500 مللي ثانية
Enter fullscreen mode Exit fullscreen mode

أما:

-rate=0
Enter fullscreen mode Exit fullscreen mode

فهو يزيل حد المعدل ويرسل بأقصى سرعة ممكنة. هذا اختبار مختلف عن اختبار معدل ثابت.

مثال على تقرير نصي:

Requests      [total, rate, throughput]  500, 100.20, 100.18
Duration      [total, attack, wait]      4.991s, 4.990s, 1.2ms
Latencies     [min, mean, 50, 90, 95, 99, max]  412us, 1.3ms, 1.1ms, 1.9ms, 2.4ms, 5.1ms, 12ms
Bytes In      [total, mean]              128500, 257.00
Bytes Out     [total, mean]              0, 0.00
Success       [ratio]                    100.00%
Status Codes  [code:count]               200:500
Error Set:
Enter fullscreen mode Exit fullscreen mode

ابدأ بقراءة هذه الأسطر:

  • Latencies: راقب خصوصًا 95 و 99.
  • Success [ratio]: يجب أن تكون مرتفعة حسب هدفك.
  • Status Codes: تحقق من وجود 5xx أو 4xx غير متوقعة.
  • Error Set: يجب أن يكون فارغًا في التشغيل الصحي.

المتوسط وحده لا يكفي. قد يكون المتوسط جيدًا بينما تكون النسبة 99 سيئة، وهذا يعني أن جزءًا من المستخدمين يرى زمن استجابة مؤلمًا.

حفظ النتائج ثم إنشاء تقارير متعددة

للتجارب السريعة، يمكنك توجيه النتائج مباشرة إلى report.

لكن في الاختبارات الجادة، احفظ النتائج الأولية أولًا:

echo "GET http://localhost:8080/" | \
  vegeta attack -duration=10s -rate=200 -output=results.bin
Enter fullscreen mode Exit fullscreen mode

ثم أنشئ تقريرًا نصيًا:

vegeta report results.bin
Enter fullscreen mode Exit fullscreen mode

أو تقرير JSON لاستخدامه في لوحة تحكم أو مقارنة تلقائية:

vegeta report -type=json results.bin > metrics.json
Enter fullscreen mode Exit fullscreen mode

أو مخططًا تكراريًا لزمن الاستجابة:

vegeta report -type='hist[0,2ms,5ms,10ms,25ms,100ms]' results.bin
Enter fullscreen mode Exit fullscreen mode

المخطط التكراري يوضح عدد الطلبات التي وقعت داخل كل نطاق زمني. استخدمه لمعرفة هل زمن الاستجابة متقارب أم منتشر على نطاق واسع.

استخدام ملف أهداف بدل طلب واحد

واجهات API الحقيقية غالبًا تحتاج أكثر من طلب GET واحد. أنشئ ملف أهداف مثل targets.txt:

GET http://localhost:8080/api/users

POST http://localhost:8080/api/users
Content-Type: application/json
@./payload.json

GET http://localhost:8080/api/users/42
Enter fullscreen mode Exit fullscreen mode

قواعد التنسيق:

  • السطر الأول لكل هدف هو METHOD URL.
  • الرؤوس تأتي مباشرة بعده، سطر لكل رأس.
  • السطر الذي يبدأ بـ @ يشير إلى ملف جسم الطلب.
  • سطر فارغ يفصل بين هدف وآخر.
  • الأسطر التي تبدأ بـ # تعليقات.

مثال جسم الطلب في payload.json:

{ "name": "Ada", "role": "engineer" }
Enter fullscreen mode Exit fullscreen mode

شغّل الاختبار:

vegeta attack -targets=targets.txt -rate=50 -duration=30s | vegeta report
Enter fullscreen mode Exit fullscreen mode

ستمر Vegeta على الأهداف بالترتيب وتكررها حتى انتهاء مدة الاختبار.

لإضافة مصادقة أو رؤوس مشتركة:

vegeta attack -targets=targets.txt -rate=50 -duration=30s \
  -header="Authorization: Bearer $TOKEN" | vegeta report
Enter fullscreen mode Exit fullscreen mode

استخدام تنسيق JSON للأهداف

إذا كنت تولّد الأهداف برمجيًا أو تشغل اختبارًا كبيرًا، استخدم تنسيق JSON:

{"method": "GET", "url": "http://localhost:8080/api/users"}
{"method": "POST", "url": "http://localhost:8080/api/users", "header": {"Content-Type": ["application/json"]}, "body": "eyJuYW1lIjoiQWRhIn0="}
Enter fullscreen mode Exit fullscreen mode

ثم شغّل:

vegeta attack -format=json -targets=targets.json -rate=100 -duration=30s | vegeta report
Enter fullscreen mode Exit fullscreen mode

حقل body يجب أن يكون مشفرًا بـ base64.

إذا كنت تولّد الأهداف أثناء التشغيل، يمكنك استخدام -lazy لتقليل استهلاك الذاكرة.

إنشاء رسوم بيانية ومقارنة تشغيلات متعددة

الأرقام المختصرة تخفي الاتجاهات. إذا بدأ زمن الاستجابة بالتدهور في منتصف الاختبار، فأنت تحتاج رؤية المنحنى.

أنشئ مخطط HTML:

vegeta attack -targets=targets.txt -rate=100 -duration=60s | \
  vegeta plot > plot.html
Enter fullscreen mode Exit fullscreen mode

افتح plot.html في المتصفح. سترى زمن الاستجابة عبر مدة التشغيل.

لمقارنة معدلات تحميل مختلفة:

vegeta attack -rate=50  -duration=30s -targets=targets.txt -output=50qps.bin
vegeta attack -rate=100 -duration=30s -targets=targets.txt -output=100qps.bin
vegeta plot 50qps.bin 100qps.bin > compare.html
Enter fullscreen mode Exit fullscreen mode

إذا كنت تعمل في بيئة CI بدون واجهة رسومية، صدّر البيانات إلى CSV:

vegeta encode -to=csv results.bin > results.csv
Enter fullscreen mode Exit fullscreen mode

متى تستخدم Vegeta

استخدم Vegeta عندما يكون السؤال عن المعدل والسعة:

  • ما زمن الاستجابة عند 500 RPS؟
  • عند أي معدل تبدأ أخطاء 5xx بالظهور؟
  • هل النسخة الجديدة أسرع من القديمة تحت نفس الحمل؟
  • هل إعداد البنية التحتية الجديد يتحمل نفس معدل الطلبات؟
  • هل يمكن تشغيل اختبار تحميل بسيط داخل CI؟

Vegeta أداة مركزة. هي ترسل طلبات HTTP بمعدل محدد وتقيس الاستجابة. لا تبني رحلات مستخدم معقدة، ولا تتحقق من صحة جسم الاستجابة، ولا تنفذ منطقًا وظيفيًا متعدد الخطوات.

هذا التركيز مفيد لأنه يجعل النتائج واضحة وقابلة للتكرار.

إذا كنت تقارنها بأدوات أخرى، راجع اختبار تحميل k6 و اختبار تحميل JMeter. وللمفاهيم الأساسية، راجع البرنامج التعليمي لاختبار أداء واجهة برمجة التطبيقات API.

أين يتناسب الاختبار الوظيفي

اختبار التحميل يجيب عن سؤال:

هل واجهة API سريعة بما يكفي تحت هذا الحمل؟

لكنه لا يجيب عن سؤال:

هل الاستجابة صحيحة؟

قد تحصل على:

Success: 100%
Status Codes: 200:500
Enter fullscreen mode Exit fullscreen mode

بينما تعيد نقطة النهاية مستخدمًا خاطئًا، أو سعرًا قديمًا، أو JSON غير مطابق للمخطط المتوقع.

لهذا تحتاج اختبارًا وظيفيًا قبل اختبار التحميل. الاختبار الوظيفي يتحقق من:

  • كود الحالة.
  • الرؤوس.
  • جسم الاستجابة.
  • مخطط JSON.
  • قواعد العمل.
  • ربط الطلبات ببعضها.

هذا هو دور الاختبار الوظيفي.

هنا يمكن أن تعمل Apidog مع Vegeta بدل أن تكون بديلًا مباشرًا لها:

  1. استخدم Apidog للتحقق من أن API تعيد البيانات الصحيحة.
  2. استخدم Vegeta لقياس هل نفس المسارات تبقى سريعة عند مئات أو آلاف الطلبات في الثانية.

مثال تثبيت Apidog CLI:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

ثم تشغيل سيناريو أو مجموعة محفوظة:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit
Enter fullscreen mode Exit fullscreen mode

شرح الخيارات:

  • -t: معرف السيناريو أو المجلد أو المجموعة.
  • -e: معرف البيئة.
  • -r: نوع التقرير مثل cli, html, json, junit.

مخرجات junit مفيدة في معظم أنظمة CI.

راجع البرنامج التعليمي لسطر أوامر Apidog CLI و دليل خط أنابيب CI/CD إذا أردت دمج الاختبارات الوظيفية قبل خطوة التحميل.

النمط العملي المقترح:

اختبار وظيفي → اختبار تحميل → تقرير ومقارنة
Enter fullscreen mode Exit fullscreen mode

مثال CI بسيط

مثال خطوة shell تحفظ نتائج Vegeta وتصدر تقرير JSON:

vegeta attack -targets=targets.txt \
  -rate=200 \
  -duration=60s \
  -output=results.bin

vegeta report results.bin
vegeta report -type=json results.bin > vegeta-metrics.json
Enter fullscreen mode Exit fullscreen mode

يمكنك إضافة شرط فشل بسيط بقراءة metrics.json عبر jq حسب معاييرك، مثل نسبة النجاح أو p99.

مثال عام:

SUCCESS=$(jq '.success' vegeta-metrics.json)

awk "BEGIN { exit !($SUCCESS >= 0.99) }"
Enter fullscreen mode Exit fullscreen mode

عدّل العتبات حسب SLO الخاص بك.

الأسئلة الشائعة

هل تدعم Vegeta طلبات POST ذات الجسم؟

نعم. في ملف أهداف HTTP، ضع الطريقة وعنوان URL في السطر الأول، ثم رأس Content-Type، ثم أشر إلى ملف الجسم باستخدام:

@./payload.json
Enter fullscreen mode Exit fullscreen mode

وفي تنسيق JSON استخدم الحقول method و url و body، مع تشفير body بـ base64.

ماذا تفعل -rate=0؟

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

-rate=500
Enter fullscreen mode Exit fullscreen mode

كيف أقرأ نسب زمن الاستجابة؟

في التقرير، راقب خصوصًا:

  • 50: الوسيط.
  • 95: 95% من الطلبات أسرع من هذه القيمة.
  • 99: 99% من الطلبات أسرع من هذه القيمة.

النسب 95 و 99 تكشف الذيل البطيء الذي قد يخفيه المتوسط.

هل يمكن لـ Vegeta التحقق من صحة البيانات؟

لا. Vegeta تقيس الإنتاجية، وزمن الاستجابة، ورموز الحالة، والأخطاء. لا تتحقق من صحة جسم الاستجابة أو المخطط. استخدم أداة اختبار وظيفي أولًا، ثم استخدم Vegeta لقياس الأداء.

كيف أشغّل Vegeta في CI؟

Vegeta ملف ثنائي واحد يعمل من shell. احفظ النتائج باستخدام -output، ثم أنشئ تقريرًا نصيًا أو JSON كـ artifact. أضف خطوة اختبار وظيفي قبل التحميل حتى تقيس فقط نقاط النهاية التي اجتازت التأكيدات.

Top comments (0)