شقلب Shaqlib: أفضل حل لمشكلة الكتابة بلغة الكيبورد الخاطئة

شرح hey HTTP Load Testing لاختبار ضغط المواقع وAPI وقياس أداء السيرفر

هل تساءلت يومًا عن عدد الطلبات التي يستطيع موقعك أو تطبيقك التعامل معها في نفس الوقت؟ أو ماذا سيحدث عندما يبدأ مئات المستخدمين في إرسال طلبات إلى API الخاص بتطبيقك؟

قد يعمل موقعك بسرعة ممتازة عندما تستخدمه بمفردك، لكن بمجرد زيادة عدد المستخدمين تبدأ الاستجابة في التباطؤ، وربما تظهر أخطاء مثل 500 Internal Server Error أو 503 Service Unavailable.

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

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

في هذا المقال سنتعرف بالتفصيل على أداة hey، وطريقة تثبيتها على macOS وLinux وWindows، وكيفية اختبار أداء API باستخدام GET وPOST، بالإضافة إلى شرح النتائج وتحديد الاختناقات المحتملة في أداء السيرفر.

ما هي أداة hey HTTP Load Testing؟

hey هي أداة تعمل من خلال سطر الأوامر Terminal أو Command Prompt، وتستخدم لاختبار أداء خوادم HTTP عن طريق إرسال طلبات متعددة خلال فترة زمنية محددة أو حتى الوصول إلى عدد معين من الطلبات.

تعد بديلًا بسيطًا لأداة ApacheBench المعروفة باسم ab، وتوفر طريقة مباشرة لاختبار سرعة استجابة مواقع الويب وواجهات API.

على سبيل المثال، يمكنك استخدام hey لإرسال 1000 طلب إلى أحد Endpoints داخل تطبيقك، مع تنفيذ 20 طلبًا بالتزامن.

وبعد انتهاء الاختبار، تعرض الأداة معلومات مثل:

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

وبذلك تستطيع معرفة كيف يتصرف السيرفر عند زيادة عدد الطلبات المتزامنة.

الأداة مكتوبة بلغة Go، وتعمل على أنظمة تشغيل متعددة، كما أنها لا تحتاج إلى واجهة رسومية أو إعدادات معقدة.

لماذا تحتاج إلى اختبار ضغط API؟

لنفترض أنك تمتلك تطبيقًا يستخدم Flutter في الواجهة الأمامية وLaravel أو ASP.NET Core في الـ Backend.

عندما يفتح المستخدم صفحة المنتجات، يقوم التطبيق بإرسال طلب إلى API لاسترجاع البيانات من قاعدة البيانات.

قد يستغرق الطلب الواحد 100 ميلي ثانية في الظروف العادية، لكن ماذا لو أرسل عدد كبير من المستخدمين طلبات متزامنة؟

قد تظهر بعض المشكلات مثل:

• زيادة استهلاك RAM داخل السيرفر.
• ارتفاع استهلاك CPU.
• بطء استعلامات MySQL أو PostgreSQL.
• استهلاك عدد كبير من اتصالات قاعدة البيانات.
• تراكم الطلبات داخل طوابير الانتظار.
• ارتفاع زمن الاستجابة تدريجيًا.
• ظهور HTTP 500 أو 502 أو 503.
• وصول بعض الطلبات إلى Timeout.

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

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

أهم مميزات أداة hey

1. تنفيذ عدد محدد من HTTP Requests

يمكنك تحديد عدد الطلبات التي تريد إرسالها باستخدام الخيار -n.

على سبيل المثال:

hey -n 100 http://localhost:8000/

يقوم هذا الأمر بإرسال 100 طلب إلى الخادم المحلي، مع استخدام عدد العمال المتزامنين الافتراضي البالغ 50 ما لم تحدده بنفسك.

ويمكن تغيير العدد حسب طبيعة الاختبار.

2. اختبار الطلبات المتزامنة Concurrency

من أهم مميزات hey إمكانية التحكم في عدد الطلبات التي تُنفذ بالتزامن باستخدام الخيار -c.

على سبيل المثال:

hey -n 1000 -c 20 http://localhost:8000/

هنا سيتم تنفيذ 1000 طلب باستخدام 20 عاملًا متزامنًا.

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

فالمستخدم الحقيقي قد يتنقل بين صفحات مختلفة وينتظر عدة ثوانٍ بين الطلبات، بينما يستطيع hey إرسال الطلبات بصورة متكررة وسريعة.

3. تحديد مدة اختبار الضغط

بدلًا من إرسال عدد ثابت من الطلبات، يمكنك تحديد مدة الاختبار باستخدام الخيار -z.

على سبيل المثال:

hey -z 30s -c 10 http://localhost:8000/

سيحاول البرنامج إرسال الطلبات لمدة 30 ثانية باستخدام 10 عمال متزامنين.

كما يمكنك استخدام:

hey -z 2m -c 10 http://localhost:8000/

لتنفيذ اختبار مدته دقيقتان.

عند تحديد مدة باستخدام -z، يتجاهل البرنامج العدد المحدد باستخدام -n.

4. تحديد معدل الطلبات Requests Per Second

يتيح hey تحديد معدل إرسال الطلبات باستخدام الخيار -q.

من المهم معرفة أن قيمة هذا الخيار تُطبّق لكل عامل متزامن، وليس على إجمالي الاختبار.

على سبيل المثال:

hey -z 30s -c 5 -q 2 http://localhost:8000/

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

لكن المعدل الفعلي قد يكون أقل بحسب زمن استجابة السيرفر وظروف الاتصال.

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

5. اختبار GET وPOST وPUT وDELETE

لا تقتصر أداة hey على اختبار صفحات الويب العادية، بل تدعم عدة طرق HTTP مثل:

• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS

وهذا يجعلها مناسبة لاختبار عدد من واجهات REST API.

يمكنك أيضًا إضافة Headers وإرسال بيانات JSON أو قراءة محتوى الطلب من ملف محلي.

6. دعم HTTP/2

تدعم أداة hey اختبار نقاط النهاية باستخدام HTTP/2 عبر الخيار التالي:

hey -h2 -n 100 -c 10 https://your-test-domain.example/api/health

استبدل الرابط بعنوان خادم HTTPS تملكه أو لديك تصريح باختباره ويدعم HTTP/2.

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

7. تصدير نتائج الاختبار إلى CSV

إذا كنت تريد الاحتفاظ بنتائج الاختبار وتحليلها لاحقًا باستخدام Python أو Excel، يمكنك استخدام:

hey -n 1000 -c 10 -o csv http://localhost:8000/ > results.csv

سيتم حفظ قياسات الطلبات في ملف CSV.

ويعد CSV صيغة الإخراج البديلة المدعومة رسميًا، إلى جانب التقرير النصي الافتراضي.

ولا توفر أداة hey خيارًا رسميًا لإخراج JSON مباشرة من خلال -o json.

كيفية تثبيت hey على macOS

إذا كنت تستخدم جهاز Mac، يمكنك تثبيت hey بسهولة من خلال Homebrew.

افتح Terminal ثم نفّذ:

brew install hey

بعد اكتمال التثبيت، تحقق من إمكانية تشغيل البرنامج:

hey -h

سيعرض البرنامج تعليمات الاستخدام والخيارات المتاحة.

وإذا كان لديك Go مثبتًا على الجهاز، يمكنك أيضًا تثبيت الأداة باستخدام:

go install github.com/rakyll/hey@latest

في هذه الحالة قد تحتاج إلى إضافة مجلد Go binaries إلى متغير PATH حتى تستطيع تشغيل الأمر hey من أي مكان.

كيفية تثبيت hey على Linux

يمكن لمستخدمي Linux تثبيت hey باستخدام Go بعد تثبيت اللغة من موقعها الرسمي.

نفّذ الأمر التالي:

go install github.com/rakyll/hey@latest

ويتم حفظ الملف التنفيذي عادة داخل:

$HOME/go/bin

يمكنك تشغيله مباشرة باستخدام:

$HOME/go/bin/hey -h

كما يوفر المستودع الرسمي ملفًا تنفيذيًا جاهزًا لأجهزة Linux بمعمارية amd64.

ويجب تحميل الملفات التنفيذية من مصادر موثوقة والتحقق منها قبل التشغيل.

كيفية تثبيت hey على Windows

يمكنك تنزيل ملف hey التنفيذي لنظام Windows من الروابط الموجودة داخل مستودع GitHub الرسمي.

بعد تنزيل الملف المناسب لمعمارية جهازك، قم بحفظه في مجلد مخصص وإعادة تسميته إلى:

hey.exe

ثم افتح PowerShell داخل المجلد ونفّذ:

.\hey.exe -h

ويمكنك كذلك تثبيت Go على Windows واستخدام:

go install github.com/rakyll/hey@latest

بعدها تأكد من وجود مجلد Go binaries داخل PATH إذا كنت تريد تشغيل hey من أي مسار.

تجربة عملية: إنشاء سيرفر محلي واختبار ضغطه

حتى تتعلم استخدام hey بطريقة آمنة، يمكنك بدء التجربة على خادم HTTP محلي بدلًا من إرسال ضغط إلى موقع على الإنترنت.

إذا كان Python مثبتًا لديك، افتح Terminal وشغّل:

python3 -m http.server 8000

سيعمل خادم HTTP بسيط على المنفذ 8000.

افتح نافذة Terminal ثانية ونفّذ:

hey -n 100 -c 5 http://127.0.0.1:8000/

سيقوم hey بإرسال 100 طلب باستخدام خمسة عمال متزامنين، ثم يعرض تقرير الأداء.

هذا الاختبار مناسب للتعرف على الأداة وفهم المخرجات، لكنه لا يمثل اختبارًا واقعيًا لأداء تطبيق Backend يعتمد على قاعدة بيانات.

بعد فهم طريقة الاستخدام، يمكنك الانتقال إلى بيئة Staging خاصة بتطبيقك.

اختبار أداء REST API باستخدام hey

لنفترض أنك تطور تطبيقًا يحتوي على API لاسترجاع المنتجات من قاعدة البيانات.

قد يكون عنوان الـ Endpoint داخل بيئة التطوير بالشكل التالي:

http://localhost:8080/api/products

يمكنك البدء باختبار بسيط:

hey -n 100 -c 5 http://localhost:8080/api/products

ثم زيادة الحمل تدريجيًا:

hey -n 300 -c 10 http://localhost:8080/api/products

بعد ذلك يمكن تجربة:

hey -n 500 -c 20 http://localhost:8080/api/products

قارن نتائج هذه الاختبارات، وراقب زمن الاستجابة والأخطاء واستهلاك الموارد.

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

لكن لا يمكن تحديد السبب اعتمادًا على نتيجة hey وحدها؛ فقد يكون السبب قاعدة البيانات أو منطق التطبيق أو الشبكة أو حدود البيئة المستخدمة.

اختبار POST API باستخدام JSON

يمكن استخدام hey لاختبار نقاط النهاية التي تستقبل بيانات JSON.

لنفترض أن لديك Endpoint تجريبيًا لمعالجة بيانات منتج:

http://localhost:8080/api/test-product

يمكنك تنفيذ الطلب التالي:

hey -n 50 -c 5 \
  -m POST \
  -T "application/json" \
  -d '{"name":"Test Product","price":100}' \
  http://localhost:8080/api/test-product

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

• -n 50: إرسال 50 طلبًا.
• -c 5: تشغيل خمسة عمال متزامنين.
• -m POST: استخدام طريقة POST.
• -T application/json: تحديد نوع المحتوى.
• -d: تحديد البيانات التي سيتم إرسالها.

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

ولهذا يجب استخدام بيئة اختبار وبيانات تجريبية، أو تصميم Endpoint آمن ومناسب لاختبارات الأداء.

إرسال JSON من ملف باستخدام hey

إذا كانت البيانات كبيرة، يمكنك حفظها داخل ملف JSON بدلًا من كتابتها بالكامل في Terminal.

أنشئ ملفًا باسم:

payload.json

وأضف بداخله:

{
  "name": "Test Product",
  "price": 120,
  "quantity": 5,
  "categoryId": 10
}

ثم نفّذ:

hey -n 50 -c 5 \
  -m POST \
  -T "application/json" \
  -D payload.json \
  http://localhost:8080/api/test-product

سيقرأ hey محتوى الملف ويرسله في جسم كل طلب.

ويعتبر هذا الخيار مناسبًا لاختبار طلبات API التي تحتوي على بيانات معقدة أو عدد كبير من الحقول.

اختبار API يحتاج إلى Authorization Token

في كثير من التطبيقات، لا يمكن الوصول إلى بعض Endpoints إلا بعد تسجيل الدخول والحصول على Access Token.

يمكنك إضافة التوكن من خلال Header باستخدام الخيار -H.

على سبيل المثال:

hey -n 100 -c 10 \
  -H "Accept: application/json" \
  -H "Authorization: Bearer YOUR_TEST_TOKEN" \
  http://localhost:8080/api/profile

استبدل YOUR_TEST_TOKEN بتوكن اختبار خاص ببيئة التطوير.

ويمكن إضافة أكثر من Header من خلال تكرار الخيار -H.

يجب عدم وضع توكنات حقيقية داخل ملفات عامة أو مستودعات GitHub، كما ينبغي الانتباه إلى أن الأوامر التي تحتوي على أسرار قد تُحفظ داخل سجل أوامر Terminal.

شرح نتائج hey HTTP Load Testing

بعد تنفيذ الاختبار، تعرض hey تقريرًا يحتوي على عدة أقسام.

لفهم النتائج بصورة أوضح، لنفترض أن أداة الاختبار أعادت القيم التوضيحية التالية:

Summary:
  Total:        5.2000 secs
  Slowest:      0.4500 secs
  Fastest:      0.0200 secs
  Average:      0.0950 secs
  Requests/sec: 96.1500

Latency distribution:
  50% in 0.0800 secs
  75% in 0.1100 secs
  90% in 0.1800 secs
  95% in 0.2400 secs
  99% in 0.4100 secs

Status code distribution:
  [200] 495 responses
  [500] 5 responses

الأرقام السابقة مثال تعليمي وليست نتائج اختبار فعلي.

1. Total

يمثل الوقت الإجمالي الذي استغرقه تنفيذ الاختبار.

في المثال السابق:

Total: 5.2000 secs

أي أن الاختبار استغرق حوالي 5.2 ثانية.

2. Average

يمثل متوسط زمن استجابة الطلبات التي حصلت على استجابة.

Average: 0.0950 secs

أي ما يعادل 95 ميلي ثانية تقريبًا.

لكن المتوسط وحده قد يكون مضللًا؛ فمن الممكن أن تكون معظم الطلبات سريعة، بينما يستغرق بعضها وقتًا طويلًا.

3. Requests/sec

هذا من أهم المقاييس التي تعرضها hey.

Requests/sec: 96.1500

يشير إلى أن معدل الطلبات المنفذة خلال الاختبار بلغ حوالي 96 طلبًا في الثانية.

لكن هذا الرقم لا يعني أن السيرفر يستطيع التعامل دائمًا مع العدد نفسه في ظروف الإنتاج الحقيقية.

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

4. Fastest وSlowest

يعرض Fastest أسرع زمن استجابة مسجل، بينما يعرض Slowest أبطأ استجابة.

وجود فرق كبير بينهما قد يشير إلى تفاوت في الأداء، لكنه لا يكفي وحده لتحديد سبب المشكلة.

5. Latency Distribution

يعتبر توزيع زمن الاستجابة من أهم المعلومات عند تحليل أداء API.

يقدم هذا القسم نسبًا مئوية مثل P50 وP90 وP95 وP99.

على سبيل المثال:

95% in 0.2400 secs

يعني أن نحو 95% من الطلبات التي حصلت على استجابة اكتملت خلال 240 ميلي ثانية أو أقل.

أما:

99% in 0.4100 secs

فيعني أن نحو 99% من الطلبات اكتملت خلال 410 ميلي ثانية أو أقل.

وتسمى هذه القيم Percentiles، وهي مفيدة لاكتشاف مشكلة الطلبات البطيئة التي قد لا تظهر بوضوح عند النظر إلى المتوسط.

6. Status Code Distribution

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

من أشهرها:

• 200: نجاح طلب HTTP.
• 201: إنشاء مورد بنجاح.
• 400: طلب غير صالح.
• 401: الطلب يحتاج إلى مصادقة صحيحة.
• 403: الوصول ممنوع.
• 404: المورد غير موجود.
• 429: تجاوز معدل الطلبات المسموح.
• 500: خطأ داخلي في السيرفر.
• 503: الخدمة غير متاحة.

إذا كان الاختبار يحتوي على 500 طلب وعاد منها خمسة طلبات بالكود 500، فإن نسبة استجابات HTTP 500 تساوي 1%.

لكن hey لا تتحقق من صحة بيانات JSON أو منطق الاستجابة نفسه، بل تعرض معلومات قياس HTTP. لذلك لا تعتبر استجابة 200 دليلًا على صحة النتيجة التجارية أو البرمجية.

كيفية معرفة سبب بطء السيرفر من نتائج hey

تتضمن التقارير قسمًا باسم Details يعرض وقت المراحل المختلفة لتنفيذ الطلب.

ومن المقاييس الموجودة:

• DNS-lookup: الوقت المستغرق في ترجمة اسم النطاق إلى عنوان IP.
• DNS+dialup: الوقت المرتبط بإعداد الاتصال.
• req write: الوقت المستغرق في إرسال الطلب.
• resp wait: الوقت المستغرق في انتظار بداية الاستجابة.
• resp read: الوقت المستغرق في قراءة بيانات الاستجابة.

إذا كان وقت resp wait مرتفعًا، فقد تحتاج إلى مراجعة معالجة الطلب داخل السيرفر أو الاعتماد على الخدمات وقاعدة البيانات.

أما إذا كانت مرحلة الاتصال بطيئة، فقد يكون من المناسب فحص الشبكة وDNS وإعدادات الاتصالات.

هذه مؤشرات مبدئية وليست تشخيصًا قاطعًا؛ لذا يفضل استخدام سجلات التطبيق وأدوات مراقبة قاعدة البيانات إلى جانب نتائج hey.

اختبار تأثير Keep-Alive على الأداء

تعتمد بعض طلبات HTTP على إعادة استخدام اتصالات TCP بدلًا من إنشاء اتصال جديد لكل طلب.

يمكنك تجربة سلوك الاتصال المعتاد:

hey -n 200 -c 10 http://localhost:8080/api/products

ثم إعادة الاختبار مع تعطيل Keep-Alive:

hey -n 200 -c 10 \
  -disable-keepalive \
  http://localhost:8080/api/products

قارن النتائج لمعرفة تأثير إعادة استخدام الاتصالات على أداء نقطة النهاية في بيئتك.

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

اختبار HTTP Redirects

في بعض الحالات، تعيد صفحات الويب توجيه المستخدم إلى عنوان مختلف باستخدام أكواد مثل 301 أو 302.

يتبع hey عمليات إعادة التوجيه افتراضيًا.

وإذا أردت تعطيل ذلك، يمكنك استخدام:

hey -n 100 -c 5 \
  -disable-redirects \
  http://localhost:8080/old-path

يساعدك ذلك على قياس استجابة نقطة إعادة التوجيه نفسها بدلًا من متابعة جميع التحويلات.

الفرق بين hey وApacheBench وk6 وJMeter

توجد أدوات متعددة لاختبار أداء مواقع الويب وواجهات API، ولكل أداة استخدام مناسب.

الأداة	أهم الاستخدامات	طريقة الاستخدام
hey	اختبار HTTP سريع وقياس زمن الاستجابة والطلبات المتزامنة.	سطر الأوامر.
ApacheBench	اختبارات HTTP بسيطة باستخدام عدد محدد من الطلبات.	سطر الأوامر.
k6	اختبارات حمل أكثر تعقيدًا تعتمد على سيناريوهات ومراحل.	سكربتات JavaScript وCLI.
JMeter	اختبارات أداء متعددة الخطوات والبروتوكولات.	واجهة رسومية وأدوات تشغيل الاختبارات.

إذا كنت تريد إجراء اختبار سريع لنقطة API واحدة، فإن hey غالبًا ستكون مناسبة.

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

أفضل طريقة لاختبار ضغط API بطريقة صحيحة

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

على سبيل المثال، يمكنك إنشاء ثلاث تجارب داخل بيئة Staging:

الاختبار الأول: حمل منخفض

hey -n 100 -c 5 \
  http://localhost:8080/api/products

الاختبار الثاني: حمل متوسط

hey -n 300 -c 10 \
  http://localhost:8080/api/products

الاختبار الثالث: حمل أعلى

hey -n 500 -c 20 \
  http://localhost:8080/api/products

بعد كل تجربة، راجع:

• عدد الطلبات في الثانية.
• متوسط زمن الاستجابة.
• P95 وP99.
• عدد استجابات 4xx و5xx.
• أخطاء الاتصال والمهلة الزمنية.
• استهلاك CPU وRAM.
• مدة تنفيذ استعلامات قاعدة البيانات.

إذا بدأت الأخطاء في الزيادة أو أصبحت الاستجابة بطيئة جدًا، أوقف زيادة الحمل وابدأ بتحليل المشكلة.

من المهم أن تكون الاختبارات على خوادم تملكها أو لديك تصريح صريح لاختبارها، لأن إرسال طلبات كثيفة إلى مواقع الآخرين قد يؤدي إلى تعطيل خدماتهم.

كيف تستخدم hey لتحسين أداء Laravel أو ASP.NET Core؟

يمكن الاستفادة من hey عند تطوير تطبيقات Backend باستخدام Laravel أو ASP.NET Core أو Node.js.

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

لنفترض أن نقطة API تسترجع قائمة كبيرة من المنتجات.

ابدأ باختبارها وسجّل النتائج.

بعد ذلك، يمكنك تجربة تحسينات مثل:

• إضافة Pagination بدلًا من استرجاع جميع السجلات.
• تحديد الحقول المطلوبة من قاعدة البيانات.
• إضافة Indexes مناسبة للاستعلامات.
• تقليل مشكلة N+1 Queries.
• استخدام Cache للبيانات التي لا تتغير باستمرار.
• تقليل حجم JSON Response.
• تجنب العمليات المكلفة التي لا يحتاج إليها كل طلب.

بعد تطبيق التحسينات، نفّذ اختبار hey مرة أخرى بنفس الإعدادات، وقارن معدلات الاستجابة والأخطاء والطلبات في الثانية.

بهذه الطريقة يمكنك قياس تأثير التحسين بصورة أكثر موضوعية.

أخطاء شائعة عند استخدام hey

الخطأ الأول: الاعتقاد أن Concurrency يعني عدد المستخدمين

عندما تكتب -c 100 فهذا يعني وجود 100 عامل لتنفيذ الطلبات بالتزامن، وليس محاكاة واقعية لسلوك 100 مستخدم.

الخطأ الثاني: اختبار بيئة الإنتاج مباشرة

قد تتسبب اختبارات الضغط في استهلاك موارد كبيرة أو تعطيل بعض الخدمات، خصوصًا عندما تكون إعدادات السيرفر غير مناسبة.

لذلك يفضل استخدام بيئة Staging أو بيئة مخصصة لاختبارات الأداء.

الخطأ الثالث: تجاهل استجابات HTTP الفاشلة

قد يعرض hey رقم Requests/sec مرتفعًا حتى لو كانت نسبة كبيرة من الاستجابات أخطاء.

لذلك لا تقارن الأداء باستخدام معدل الطلبات فقط، بل راجع أيضًا أكواد HTTP وأخطاء الاتصال.

الخطأ الرابع: إرسال POST إلى عمليات حساسة

قد يؤدي اختبار نقاط تسجيل المستخدمين أو إنشاء الفواتير أو تنفيذ المدفوعات إلى حدوث عمليات فعلية متعددة.

استخدم بيانات تجريبية ونقاط نهاية مخصصة، ولا تختبر عمليات مالية حقيقية أو إرسال إشعارات فعلية دون عزل البيئة.

الخطأ الخامس: الاعتماد على اختبار واحد

يمكن أن تتأثر النتائج بعوامل مثل التخزين المؤقت وحالة قاعدة البيانات والحمل الموجود على السيرفر.

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

الأسئلة الشائعة حول hey HTTP Load Testing

هل أداة hey مجانية؟

نعم، hey أداة مفتوحة المصدر ومتاحة تحت رخصة Apache 2.0، ويمكن استخدامها دون شراء اشتراك.

هل تعمل hey على Windows وMac وLinux؟

نعم، يوفر المشروع ملفات تنفيذية لأنظمة تشغيل متعددة، ويمكن تثبيته باستخدام Go، كما يدعم التثبيت عبر Homebrew على macOS.

هل يمكن اختبار REST API باستخدام hey؟

نعم، تدعم الأداة طرق HTTP المختلفة وإرسال Headers وبيانات JSON، مما يجعلها مفيدة لاختبار أداء نقاط REST API.

هل يمكن اختبار 1000 طلب متزامن؟

يمكن تحديد عدد كبير من العمال باستخدام الخيار -c بشرط ألا يتجاوز عدد الطلبات المحدد عند استخدام -n. لكن نجاح الاختبار يعتمد على موارد جهاز الاختبار والخادم والشبكة، ويجب زيادة الحمل تدريجيًا داخل بيئة مصرح بها.

هل hey تكشف سبب بطء قاعدة البيانات؟

لا تكشف السبب مباشرة، لكنها تساعدك على قياس أداء Endpoint. ويمكن دمج النتائج مع أدوات مراقبة قاعدة البيانات وسجلات التطبيق لتحديد مصدر البطء.

هل يمكن حفظ نتائج الاختبار؟

نعم، يمكنك حفظ التقرير النصي في ملف أو استخدام خيار -o csv لتصدير قياسات الطلبات بصيغة CSV.

هل تدعم HTTP/2؟

نعم، توفر الخيار -h2 لاستخدام HTTP/2 مع نقاط النهاية المدعومة.

هل يمكن استخدامها لاختبار تطبيق Flutter؟

يمكنك استخدامها لاختبار Backend API الذي يتصل به تطبيق Flutter، لكنها ليست أداة لقياس أداء واجهة Flutter أو استهلاك الذاكرة داخل التطبيق نفسه.

الخلاصة

تعد hey HTTP Load Testing من الأدوات البسيطة والمفيدة لأي مطور يرغب في قياس أداء مواقع الويب أو واجهات REST API تحت الضغط.

فبدلًا من الاعتماد على تجربة طلب واحد من المتصفح أو Postman، يمكنك إرسال مئات الطلبات مع التحكم في عدد العمال المتزامنين ومعدل الإرسال ومدة الاختبار.

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

كما أنها مناسبة لمطوري Laravel وASP.NET Core وNode.js والمطورين الذين يعملون على تطبيقات Flutter وReact Native ويحتاجون إلى اختبار أداء الخوادم التي تعتمد عليها تطبيقاتهم.

ورغم أن hey ليست بديلًا كاملًا لأدوات اختبار الحمل المتقدمة، فإنها تعتبر خيارًا ممتازًا لبدء قياس أداء API بسرعة ومن خلال أوامر بسيطة.

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

تحميل أداة hey مجانًا من GitHub

يمكنك تحميل hey والاطلاع على الكود المصدري والتعليمات الرسمية من خلال الرابط التالي:

تحميل hey HTTP Load Testing من GitHub