اختبار أداء واجهات API

لماذا يهم

كل شاشة في التطبيق وكل تكامل مع شريك سلسلةٌ من استدعاءات API، فنقطة نهاية بطيئة واحدة تُبطئ كل شاشة تستدعيها، وفي الاستدعاءات المتتابعة تتراكم التأخيرات. ومشكلات مثل قائمة بلا حدّ أعلى أو قفل على صف يكثر الطلب عليه تبقى غير مرئية في الاختبارات الوظيفية، التي ترسل طلباً واحداً في كل مرة ببيانات قليلة.

وبالنسبة إلى المختبِر، تحوّل أهداف نقاط النهاية عبارة «التطبيق يبدو بطيئاً» إلى نتيجة قابلة للإبلاغ: أي نقطة نهاية، وأي مئين، وعند أي حمل، ومقابل أي هدف. ويمكن أن تبدأ الاختبارات على مستوى API بمجرد وجود نقطة النهاية، قبل اختبار الحمل الشامل من طرف إلى طرف بوقت طويل.

هدف لكل نقطة نهاية، لا هدف واحد للواجهة كلها

تؤدي نقاط النهاية أعمالاً مختلفة جداً: ففحص السلامة (Health Check) يعيد قيمة ثابتة، وجلب عنصر بمعرّفه يقرأ صفاً واحداً، والبحث يرشّح آلاف السجلات، وإنشاء طلب شراء يكتب في عدة جداول وقد يستدعي مزوّد دفع. والهدف الواحد لـ«الواجهة كلها»، مثل «كل شيء تحت ⁦500⁩ مللي ثانية»، يُخفي الانحدار في نقاط النهاية الخفيفة، ولا يمكن تحقيقه في الثقيلة.

الهدف القابل للاختبار يذكر نقطة النهاية وطريقتها، والمئين (p95، وغالباً p99 أيضاً)، والعتبة، والحمل الذي يجب أن يتحقق عنده، ومعدل الأخطاء المقبول، وشرط البيانات مثل حجم الصفحة. فعبارة «p95 أقل من ⁦200⁩ مللي ثانية» بلا مستوى حمل لا يمكن أن تنجح ولا أن تفشل. وتأتي الأهداف من المتطلبات غير الوظيفية أو أهداف مستوى الخدمة (SLO)، ومن حاجة العميل (فالشاشة التي تستدعي نقطتي نهاية بالتتابع عليها أن تقسم ميزانيتها الزمنية بينهما)، ومن مراقبة بيئة الإنتاج. والجدول مثال من فريق واحد، لا معيار.

العمل البطيء مثل التصدير الكبير لا ينبغي أن يُبقي الطلب مفتوحاً. والتصميم الشائع أن يجيب الخادم فوراً بـ202 Accepted (في RFC 9110: قُبل الطلب للمعالجة لكنها لم تكتمل) ثم يجلب العميل النتيجة لاحقاً؛ فتختبر عندها هدفين: زمن قبول الطلب، والزمن حتى تصبح النتيجة جاهزة.

Shop API: targets at the expected peak (an example agreed by one team)

Endpoint                      Load        p95       p99       Errors
GET  /health                  20 req/s    <= 50 ms  <= 100 ms 0 %
GET  /products/{id}           150 req/s   <= 200 ms <= 400 ms < 0.1 %
GET  /products?q=...&limit=20 60 req/s    <= 500 ms <= 1 s    < 0.1 %
POST /orders                  10 req/s    <= 800 ms <= 1.5 s  < 0.1 %
POST /reports/export          1 req/min   202 Accepted <= 300 ms; file ready <= 60 s

جرّبها: محلّل زمن الاستجابة جرّبها: مقارنة أداء API

حجم الحمولة جزء من زمن الاستجابة

زمن الاستجابة الذي يراه العميل يشمل بناء جسم الاستجابة وإرساله وتحليله. ونقطة النهاية نفسها قد تكون سريعة مع ⁦20⁩ عنصراً وبطيئة مع ⁦2000⁩، وسريعة على شبكة المكتب وبطيئة على اتصال الهاتف. فاختبر كل نقطة نهاية بالأحجام التي سترسلها وتستقبلها فعلاً.

• قِس جسم الاستجابة خاماً وكما يُنقل فعلاً: حين يرسل العميل Accept-Encoding: gzip، هل تحمل الاستجابة Content-Encoding، وكم بايتاً توفّر؟
• القوائم يجب أن تكون محدودة: اختبر حجم الصفحة الافتراضي، والحد الأقصى الموثّق، وقيمة أعلى منه. فالطلب limit=100000 يجب أن يُقيَّد أو يُرفض، لا أن يُخدَم.
• كبّر البيانات: استدعِ نقطة النهاية نفسها لعميل لديه ⁦5⁩ طلبات ولآخر لديه ⁦5000⁩ طلب. والزمن الذي ينمو مع البيانات يشير إلى ترقيم صفحات (Pagination) مفقود أو إلى استعلام لكل عنصر.
• طبّق تحليل القيم الحدّية على أجسام الطلبات: قِس زمن نقطة نهاية دفعية (Batch) بعنصر واحد، وبعدد معتاد، وبالحد الأقصى الموثّق، ثم أرسل عنصراً واحداً فوق الحد الأقصى وتوقّع استجابة 4xx سريعة وموثّقة، لا انتهاء مهلة بطيئاً. وللجسم الذي يتجاوز حدّ الحجم لدى الخادم يعرّف RFC 9110 الرمز 413 Content Too Large.

جرّبها: محلّل حجم الاستجابة جرّبها: مولّد مجموعات بيانات JSON الكبيرة

التزامن: طلب واحد سريع لا يثبت الكثير

يرسل اختبار API الوظيفي طلباً واحداً في كل مرة، فلا يُظهر إلا أفضل حالة. أما مع التزامن (Concurrency) فتتنافس الطلبات على خيوط المعالجة واتصالات قاعدة البيانات والأقفال واستدعاءات الخدمات التابعة، ونقطة النهاية التي تجيب وحدها في ⁦80⁩ مللي ثانية قد تنتظر في الطابور ثوانيَ. وباستخدام نماذج حمل العمل من الدروس السابقة، صعّد الحمل على درجات: خط أساس لمستخدم واحد، ثم الذروة المتوقعة (أعلى حركة مرور متوقعة بحسب التحليلات أو تقديرات العمل)، ثم ما فوقها، وهذا هو اختبار الإجهاد (Stress Testing). وسجّل عند كل درجة p95 وp99 والإنتاجية ومعدل الأخطاء.

ومكان وصول الطلبات مهم أيضاً. فالطلبات الموزعة على سجلات كثيرة تختبر المسار العادي؛ والطلبات الكثيرة على سجل واحد، مثل منتج مخفّض في موسم التخفيضات، تختبر الأقفال. صمّم الحالتين عن قصد: بيانات اختبار متنوعة للأولى، وسجلاً «ساخناً» واحداً للثانية.

• تحقق من الصحة لا من التوقيت وحده: تأكد من رمز الحالة والحقول الأساسية في كل استجابة، ثم افحص الآثار الجانبية بعد التشغيل، مثل ألا يُباع من المخزون أكثر مما فيه، وألا يُنشأ طلب مرتين حين يعيد العميل المحاولة.
• افصل الرفض المتوقع عن الإخفاقات: فوق حدّ المعدل (Rate Limit) الموثّق توقّع 429 Too Many Requests ‏(RFC 6585)، واحسبه بمعزل عن أخطاء 5xx وانتهاء المهلة مثل 504 Gateway Timeout.

جرّبها: مولّد اختبارات الطلبات المتزامنة

مثال تطبيقي: واجهة متجر قبل موسم تخفيضات

يستعد متجر لعطلة نهاية أسبوع فيها تخفيضات. يشغّل المختبِر نقاط نهاية المنتج والبحث والطلبات من الجدول بمعدلات ذروتها لمدة ⁦15⁩ دقيقة في بيئة ما قبل الإنتاج (Staging) بحجم يشبه الإنتاج، مع ⁦20000⁩ معرّف منتج و⁦2000⁩ عميل اختبار، ومن مولّدات حمل على أجهزة منفصلة. والنتائج كما تُكتب في التقرير:

• GET /products/{id}: بلغ p95 ‏⁦140⁩ مللي ثانية وp99 ‏⁦260⁩ مللي ثانية، بلا أخطاء. ضمن الهدف.
• GET /products?q=... مع القيمة الافتراضية limit=20: بلغ p95 ‏⁦430⁩ مللي ثانية، ضمن الهدف. لكن زر «عرض الكل» في تطبيق الويب يرسل limit=200: ⁦1.8⁩ ميغابايت دون ضغط، وp95 ‏⁦1900⁩ مللي ثانية. الملاحظة: لا حدّ أقصى لحجم الصفحة.
• POST /orders بمعدل ⁦10⁩ طلبات في الثانية موزعة على منتجات كثيرة: بلغ p95 ‏⁦650⁩ مللي ثانية، ضمن الهدف. وحين يطلب ⁦50⁩ مستخدماً افتراضياً منتجاً مخفّضاً واحداً في اللحظة نفسها، يرتفع p95 إلى ⁦1400⁩ مللي ثانية وتنتهي ⁦2%⁩ من الطلبات بـ504 Gateway Timeout. الملاحظة: الطلبات تنتظر في الطابور على تحديث مخزون ذلك المنتج.
• وبعد التشغيل تطابق مستويات المخزون الطلبات المنشأة: لم يُبَع شيء أكثر من المتاح ولم يتكرر أي طلب. فمشكلة التزامن هنا بطء، لا تلف في البيانات.

الأدوات: من طلب واحد إلى اختبار حمل بسكربت

تغطي الأدوات الصغيرة الخطوات المحيطة باختبار الحمل. فأداة Response Time Analyzer في متقن تعطي خط أساس لمستخدم واحد لنقطة نهاية واحدة من ⁦20⁩ طلباً متتابعاً على الأكثر (الأدنى والأقصى والمتوسط والوسيط وp95)؛ وتعرض Response Size Analyzer، لعنوان URL أو لجسم استجابة تلصقه، البايتات الخام وحجماً مضغوطاً تقديرياً وأكبر الحقول؛ وتضع API Performance Comparator نقطتي نهاية جنباً إلى جنب؛ وتشغّل HTTP Request Benchmark قياساً صغيراً محدوداً. وترسل هذه الأدوات طلباتها من خادم متقن، فلا تصل إلا إلى عناوين URL العامة، وتشمل أزمنتها مسار الشبكة من ذلك الخادم. ولا تولّد أيٌّ منها حملاً بحجم الإنتاج.

ولذلك تحتاج إلى مولّد حمل. فأداة k6 تشغّل سكربتات JavaScript تُفشل عتباتُها (Thresholds) التشغيلَ إذا لم يتحقق هدف؛ وApache JMeter يبني خطط الاختبار في واجهة رسومية ويقرأ بيانات الاختبار عبر CSV Data Set Config، ويجب تشغيله دون الواجهة الرسومية في الاختبار الفعلي؛ وGatling وLocust ‏(Python) خياران شائعان آخران. وسكربت k6 أدناه يرمّز هدف جلب المنتج. ولا تُجرِ اختبار حمل إلا على أنظمة تملكها أو لديك إذن مكتوب باختبارها: فاختبار الحمل غير المعلن يبدو لمزوّد الطرف الثالث هجوماً لحجب الخدمة.

// Run: k6 run -e BASE_URL=https://staging.example.com product-lookup.js
import http from 'k6/http';
import { check } from 'k6';
import { SharedArray } from 'k6/data';

// 20,000 product ids: varied data, so requests do not all hit one cached record
const ids = new SharedArray('ids', () =>
  open('./product-ids.txt').split(/\r?\n/).filter(Boolean));

export const options = {
  scenarios: {
    product_lookup: {
      executor: 'constant-arrival-rate', // open model: a fixed rate of new requests
      rate: 150,
      timeUnit: '1s',
      duration: '15m',
      preAllocatedVUs: 50,
      maxVUs: 300,
    },
  },
  thresholds: {
    'http_req_duration{endpoint:product}': ['p(95)<=200', 'p(99)<=400'],
    'http_req_failed{endpoint:product}': ['rate<0.001'],
  },
};

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const res = http.get(`${__ENV.BASE_URL}/products/${id}`, {
    tags: { endpoint: 'product' },
  });
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body has a price': (r) => r.status === 200 && r.json('price') !== undefined,
  });
}

جرّبها: قياس أداء طلبات HTTP جرّبها: مولّد اختبارات الطلبات المتزامنة جرّبها: مولّد بيانات اختبار التحميل

أسئلة شائعة

المراجع

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
• RFC 6585: Additional HTTP Status CodesIETF · 2012يعرّف الرموز 428 و429 (طلبات كثيرة جداً) و431 و511، بما فيها ترويسة Retry-After لتحديد المعدل.
• Grafana k6 documentationGrafana Labsالتوثيق الرسمي لأداة Grafana k6، وهي أداة مفتوحة المصدر وقابلة للتوسعة لاختبار الحمل والأداء.