لقد كتبت نقطة نهاية HTTP. وهي تعمل عندما تستخدمها مرة واحدة من Postman. ولكن ماذا يحدث عندما يستخدمها 200 عميل في نفس الوقت؟ أنت بحاجة إلى أرقام: الطلبات في الثانية، نسب مئوية لوقت الاستجابة، وعدد الردود التي جاءت بحالة غير 2xx. يمنحك autocannon هذه الأرقام من طرفيتك في حوالي عشر ثوانٍ.
autocannon هي أداة قياس أداء HTTP/1.1 مكتوبة بلغة Node.js. تقوم بإطلاق سيل متحكم فيه من الطلبات على عنوان URL وتقدم تقارير حول الإنتاجية ووقت الاستجابة. يرشدك هذا الدليل خلال التثبيت، والتشغيل الأساسي، وكل علامة ستستخدمها بالفعل، وقراءة المخرجات، وتشغيل autocannon من نص برمجي لـ Node. كما يرسم خطاً واضحاً بين ما يخبرك به اختبار التحميل وما لا يخبرك به، حتى تعرف متى يجب اللجوء إلى اختبار وظيفي وتعاقدي بدلاً من ذلك.
ما هو autocannon
يفتح autocannon عددًا ثابتًا من الاتصالات المتزامنة بعنوان URL ويستمر في إرسال الطلبات لمدة محددة (أو عدد محدد من الطلبات). أثناء تشغيله، يقوم بأخذ عينات من وقت الاستجابة ويعد الردود. عند الانتهاء، يطبع جدولًا للنسب المئوية لوقت الاستجابة وملخصًا لإجمالي الطلبات والبايتات المقروءة.
يقيس شيئًا واحدًا: مقدار الحمل الذي يتعامل معه خادمك ومدى سرعة استجابته تحت هذا الحمل. إنه لا يتحقق مما إذا كان نص الاستجابة صحيحًا، أو ما إذا كان واجهة برمجة التطبيقات (API) الخاصة بك تتطابق مع مواصفات OpenAPI الخاصة بها، أو ما إذا كان سير العمل متعدد الخطوات يُرجع البيانات الصحيحة في كل خطوة. ضع هذا التمييز في الاعتبار. إنه يحدد مكان autocannon في مكدس الاختبار الخاص بك، والذي سيتم تغطيته قرب النهاية.
إذا كنت قد استخدمت wrk أو Apache Bench، فإن autocannon يملأ نفس الفجوة بتثبيت أصلي لـ Node وواجهة برمجة تطبيقات (API) برمجية يمكنك استدعاؤها من JavaScript.
التثبيت
يأتي autocannon كحزمة npm. قم بتثبيته عالميًا للحصول على الأمر `autocannon` في أي مكان:
npm i autocannon -g
تحتاج إلى تثبيت Node.js أولاً. إذا كنت تفضل عدم التثبيت عالميًا، قم بتشغيله عند الطلب باستخدام `npx`:
npx autocannon http://localhost:3000
أو أضفه إلى مشروع كاعتماد تطوير عندما تخطط لبرمجته:
npm i autocannon --save-dev
تحقق من التثبيت:
autocannon --version
التشغيل الأساسي
أبسط شكل هو الأمر بالإضافة إلى عنوان URL. يقوم هذا بتشغيل الاختبار الافتراضي: 10 اتصالات لمدة 10 ثوانٍ.
autocannon http://localhost:3000
تحكم في الإعدادات بثلاث علامات ستستخدمها باستمرار. `-c` تحدد عدد الاتصالات المتزامنة، و`-d` تحدد المدة بالثواني، و`-p` تحدد التوصيل المتسلسل (كم عدد الطلبات التي يرسلها كل اتصال قبل انتظار الاستجابة).
autocannon -c 100 -d 30 -p 10 http://localhost:3000
يفتح هذا الأمر 100 اتصال، ويعمل لمدة 30 ثانية، ويرسل 10 طلبات متسلسلة لكل اتصال. تؤدي أعداد الاتصالات والتوصيل المتسلسل الأعلى إلى زيادة الحمل، وهي الطريقة التي تجد بها النقطة التي يبدأ فيها وقت الاستجابة بالارتفاع.
لإرسال عدد ثابت من الطلبات بدلاً من التشغيل لمدة معينة، استخدم `-a` (الكمية):
autocannon -c 10 -a 10000 http://localhost:3000
يتوقف ذلك بعد 10,000 طلب بغض النظر عن الوقت.
طلبات POST، الرؤوس، والجسم
غيّر الطريقة باستخدام `-m`، أضف الرؤوس باستخدام `-H`، ومرر نص الطلب باستخدام `-b`. إليك طلب POST إلى نقطة نهاية JSON:
autocannon -c 50 -d 20 \
-m POST \
-H 'Content-Type=application/json' \
-H 'Authorization=Bearer YOUR_TOKEN' \
-b '{"name":"load-test","active":true}' \
http://localhost:3000/api/users
لاحظ تنسيق الرأس: `-H 'مفتاح=قيمة'`، وتكرر `-H` لكل رأس. إذا كان جسم الطلب كبيرًا أو موجودًا في ملف، استخدم `-i` لقراءته من القرص بدلاً من تضمينه مباشرةً:
autocannon -m POST -H 'Content-Type=application/json' -i payload.json http://localhost:3000/api/users
تحديد معدل الاختبار
افتراضيًا، يرسل autocannon بأقصى سرعة ممكنة. أحيانًا قد ترغب في معدل ثابت وواقعي بدلاً من تدفق بأقصى ضغط. يحدد `-R` الحد الأقصى لإجمالي الطلبات في الثانية عبر جميع الاتصالات:
autocannon -c 50 -R 500 -d 60 http://localhost:3000
هذا يحافظ على الاختبار عند 500 طلب في الثانية لمدة 60 ثانية. هذا مفيد عندما ترغب في قياس وقت الاستجابة عند حمل إنتاجي متوقع بدلاً من نقطة الانهيار.
الإحماء وسلاسل العمال
علامتان أخريان تساعدان في التشغيلات الأثقل. `-W` (الإحماء) يرسل حركة المرور لفترة قصيرة قبل أن يبدأ autocannon في أخذ العينات، لذلك لا تتأثر أرقامك الأولى بذاكرات التخزين المؤقت الباردة أو محرك JIT الذي لم يسخن بعد. `-w` (العمال) يوزع الحمل عبر سلاسل عمال Node متعددة، وهو أمر مهم عندما لا تستطيع سلسلة واحدة توليد ما يكفي من الطلبات لإشباع خادم سريع:
autocannon -c 200 -d 30 -w 4 http://localhost:3000
استخدم `-w` فقط عندما تكون قد تأكدت من أن مولد الحمل نفسه هو عنق الزجاجة. إذا بدا وقت الاستجابة مسطحًا بشكل مريب عندما ترفع `-c`، فقد يكون مولدك قد وصل إلى أقصى طاقته، وإضافة العمال تمنحك صورة أوضح لسقف أداء الخادم.
قراءة النتائج
عندما ينتهي التشغيل، يطبع autocannon جدولًا لوقت الاستجابة وسطرًا ملخصًا. مثال مختصر:
Running 10s test @ http://localhost:3000
10 connections
┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ الإحصائية │ 2.5% │ 50% │ 97.5% │ 99% │ المتوسط │ الانحراف المعياري │ الحد الأقصى │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ وقت الاستجابة │ 0 ms │ 1 ms │ 4 ms │ 6 ms │ 1.2 ms │ 0.9 ms │ 24.1 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘
251 ألف طلب في 10.05 ثانية، 27.9 ميجابايت قراءة
إليك كيفية قراءتها:
- أعمدة النسب المئوية (2.5%، 50%، 97.5%، 99%) أهم من المتوسط. عمود 50% هو الوسيط. يخبرك عمود 99% بوقت الاستجابة الذي يراه أبطأ 1 بالمائة من المستخدمين لديك. وقت الاستجابة المتأخر هو حيث تختبئ المشاكل الحقيقية، لذا راقب أرقام 97.5% و 99%.
- المتوسط والانحراف المعياري يمنحانك المتوسط ومدى تشتت أوقات الاستجابة. يعني الانحراف المعياري المرتفع أوقات استجابة غير متسقة.
- سطر الملخص ("251 ألف طلب في 10.05 ثانية") هو إنتاجيتك. قسّم الطلبات على الثواني للحصول على عدد الطلبات في الثانية.
علامتان تجعلان المخرجات أكثر فائدة. أضف `-l` لطباعة المجموعة الكاملة من النسب المئوية لوقت الاستجابة (بما في ذلك p99.9 وما بعدها)، وأضف `--renderStatusCodes` لرؤية تفاصيل لكل رمز حالة حتى تتمكن من اكتشاف موجة من أخطاء 500 تختبئ وراء رقم إنتاجية جيد:
autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
راقب أعداد الأخطاء، والمهلات، والرموز غير 2xx. يمكن للخادم أن يقدم معدل طلبات مرتفعًا بينما يُرجع أخطاء بصمت. إذا لم تكن الأرقام غير 2xx صفرًا، فإن رقم إنتاجيتك يقيس الفشل، وليس النجاح.
الاستخدام البرمجي في نص برمجي
يوفر autocannon واجهة برمجة تطبيقات Node.js، حتى تتمكن من تشغيل اختبارات الأداء من نص برمجي والتصرف بناءً على النتائج. هذا هو المكان الذي يثبت فيه جدارته في الأتمتة: تشغيل اختبار، قراءة الأرقام، وإفشال البناء إذا تجاوز وقت الاستجابة عتبة معينة.
تستقبل الدالة الأساسية كائن خيارات وتُرجع وعدًا (promise):
const autocannon = require('autocannon')
async function run() {
const result = await autocannon({
url: 'http://localhost:3000',
connections: 100,
duration: 20,
pipelining: 1
})
console.log(`متوسط وقت الاستجابة: ${result.latency.average} ms`)
console.log(`الطلبات/ثانية: ${result.requests.average}`)
console.log(`غير 2xx: ${result.non2xx}`)
}
run()
يحمل الكائن `result` رسومًا بيانية لـ `latency` (وقت الاستجابة)، و`requests` (الطلبات)، و`throughput` (الإنتاجية)، كل منها يحتوي على حقول `average` (المتوسط)، و`min` (الحد الأدنى)، و`max` (الحد الأقصى)، وحقول النسبة المئوية مثل `p99`. كما يحمل أعداد `errors` (الأخطاء)، و`timeouts` (المهلات)، و`non2xx` (غير 2xx).
لتحويل ذلك إلى بوابة، أضف فحصًا يخرج بقيمة غير صفرية عندما يتم تجاوز الميزانية:
const autocannon = require('autocannon')
const P99_BUDGET_MS = 250
async function run() {
const result = await autocannon({
url: 'http://localhost:3000/api/health',
connections: 100,
duration: 30
})
const p99 = result.latency.p99
console.log(`وقت استجابة p99: ${p99} ms (الميزانية ${P99_BUDGET_MS} ms)`)
if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
console.error('تم تجاوز ميزانية الأداء')
process.exit(1)
}
}
run()
إذا كنت تريد شريط التقدم المباشر وجدول النتائج الذي تظهره واجهة سطر الأوامر (CLI)، قم بتمرير الكائن إلى `autocannon.track`:
const autocannon = require('autocannon')
const instance = autocannon({
url: 'http://localhost:3000',
connections: 10,
duration: 10
}, console.log)
autocannon.track(instance, { renderProgressBar: true })
process.once('SIGINT', () => instance.stop())
بالنسبة لسيناريو متعدد الطلبات، قم بتمرير مصفوفة `requests` بحيث يتكرر كل اتصال عبر عدة استدعاءات:
autocannon({
url: 'http://localhost:3000',
connections: 20,
duration: 15,
requests: [
{ method: 'GET', path: '/api/users' },
{ method: 'POST', path: '/api/data', body: '{"x":1}',
headers: { 'Content-Type': 'application/json' } }
]
}, console.log)
autocannon مقابل wrk و ab
تجيب الأدوات الثلاثة على نفس السؤال (مدى السرعة، تحت أي حمل)، ويعتمد الاختيار الصحيح على حزمة التقنيات الخاصة بك.
- **Apache Bench (ab)** هي الأداة الكلاسيكية ذات الملف التنفيذي الواحد. إنها متوفرة في كل مكان وبسيطة، ولكنها أحادية الخيط وقديمة.
- **wrk** سريعة ويمكنها توليد حمل ثقيل باستخدام برمجة Lua للطلبات المخصصة. إنها أداة C مجمعة، لذا تقوم بتثبيتها خارج npm.
- **autocannon** يضاهي wrk في الإنتاجية لمعظم أعباء العمل ويتفوق في سهولة الاستخدام إذا كنت تستخدم Node بالفعل: `npm i` للتثبيت، واجهة برمجة تطبيقات JavaScript للبرمجة النصية، ودعم للتوصيل المتسلسل وملفات HAR وسيناريوهات لكل طلب جاهزًا للاستخدام.
إذا كانت Node هي بيئة التشغيل الخاصة بك، فإن autocannon هو الخيار الأقل تعقيدًا. هل تفضل أدوات Python؟ انظر كيفية اختبار التحميل بدون Python. هل تريد خيارًا قابلًا للبرمجة مع مجموعة ميزات كبيرة؟ قارن اختبار التحميل k6.
أين يتناسب الاختبار الوظيفي و Apidog
يخبرك autocannon أن نقطة النهاية الخاصة بك تخدم 12,000 طلب في الثانية مع p99 يبلغ 40 مللي ثانية. لكنه لا يخبرك ما إذا كانت نقطة النهاية تُرجع البيانات الصحيحة. يمكن لاختبار التحميل أن ينجح بامتياز بينما تعيد واجهة برمجة التطبيقات JSON مشوهًا، أو تتجاهل رأس المصادقة، أو تنحرف عن عقد OpenAPI الخاص بها. الإنتاجية ليست صحة.
هذه هي الفجوة التي يملؤها الاختبار الوظيفي والتعاقدي، وهنا Apidog يكمل أداة التحميل بدلاً من استبدالها. Apidog ليس مولد تحميل. إنه يشغل سيناريوهات اختبار محفوظة تتحقق من رموز الحالة، ومخططات الاستجابة، والقيم عبر التدفقات متعددة الخطوات، حتى تتمكن من اكتشاف الأخطاء التي لا يمكن لاختبار الأداء رؤيتها.
يمكنك تشغيل كليهما في CI، وهما يجيبان على أسئلة مختلفة. استخدم autocannon (أو wrk) للإجابة على سؤال "هل هو سريع بما يكفي تحت الحمل؟" استخدم واجهة سطر أوامر Apidog (CLI) للإجابة على سؤال "هل هو صحيح؟" واجهة سطر أوامر Apidog (CLI) لا تحتوي على واجهة رسومية وتشغل سيناريوهات أو مجموعات اختبار محفوظة من أي خطوة CI تحتوي على Node:
npm install -g apidog-cli
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
العلامة `-t` تستهدف سيناريو أو مجلد أو مجموعة محفوظة بالمعرف، و`-e` تحدد البيئة، و`-r` تختار واحدًا أو أكثر من أدوات التقارير (cli, html, json, junit) بحيث ينتج التشغيل عناصر يمكن لخط أنابيبك أرشفتها. للحصول على شرح مفصل، راجع كيفية تشغيل اختبارات API من Apidog CLI، وخط أنابيب CI/CD (النسخ واللصق)، وسير عمل GitHub Actions.
يقوم خط أنابيب سليم بتشغيل فحوصات وظيفية وتعاقدية عند كل عملية دفع (هل يعمل؟)، ثم يقوم بتشغيل اختبار تحميل قبل الإصدار (هل يصمد؟). autocannon يمتلك السؤال الثاني. Apidog يمتلك الأول.
الأسئلة الشائعة
هل autocannon دقيق لاختبار التحميل في الإنتاج؟
ينتج autocannon أرقامًا موثوقة للإنتاجية ووقت الاستجابة لنقاط نهاية HTTP/1.1، وعندما تحدد معدلًا مستهدفًا باستخدام `-R`، فإنه يصحح التخلف المنسق (coordinated omission)، وهي خطوة تتجاهلها العديد من الأدوات الأبسط. للحصول على نتائج دقيقة، قم بتشغيله من جهاز قريب من خادمك (وإلا فإن تأخر الشبكة سيطغى) واستخدم عددًا كافيًا من الاتصالات لإشباع نقطة النهاية. قم بتشغيله مقابل بيئة تدريجية (staging environment) تحاكي الإنتاج، وليس مقابل خادم التطوير الخاص بجهاز الكمبيوتر المحمول الخاص بك.
هل يدعم autocannon بروتوكول HTTP/2 أو WebSockets؟
لا. autocannon يقيس أداء HTTP/1.1. لاختبار تحميل HTTP/2 أو WebSocket، تحتاج إلى أداة مختلفة. هذا هو القيد الرئيسي الذي يجب التحقق منه قبل اختياره.
كم عدد الاتصالات التي يجب أن أستخدمها؟
ابدأ بالعدد الافتراضي 10، ثم زد `-c` حتى يتوقف عدد الطلبات في الثانية عن الارتفاع ويبدأ وقت الاستجابة في التسلق. هذه النقطة الحرجة هي تقريبًا قدرة خادمك. الدفع بما يتجاوزها بكثير يقيس حدود مولد الحمل الخاص بك أكثر من حدود خادمك.
هل يمكنني تشغيل autocannon في CI؟
نعم. واجهة برمجة التطبيقات (API) البرمجية مصممة لذلك: قم بتشغيل اختبار أداء، اقرأ `result.latency.p99` و `result.non2xx`، واستدعِ `process.exit(1)` عندما يتم تجاوز الميزانية. هذا يحول اختبار الأداء إلى بوابة نجاح/فشل يمكنك ربطها بأي خطوة CI قادرة على تشغيل Node.
ما الفرق بين `-a` و `-d`؟
`-d` يعمل لعدد من الثواني. `-a` يعمل حتى يكتمل عدد من الطلبات، ثم يتوقف. استخدم `-d` لاختبار حمل مستقر واستخدم `-a` عندما تريد إرسال عدد دقيق من الطلبات.