اختبار أداء مشروع ويب جامعي وقراءة نتائج زمن الاستجابة

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

صِف التجربة قبل الرقم

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

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

اقرأ ثلاثة مؤشرات متكاملة

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

سكريبت محلي بمسار واضح

نفترض API تجريبيًا على 127.0.0.1:8000 يعيد في /health كائن JSON يحوي database: "ready". اضبطه لبيئتك. العتبات أدناه افتراضية لتوضيح الآلية، وليست تعهد أداء أو أرقامًا أُنجزت.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '10s', target: 2 },
    { duration: '20s', target: 2 },
    { duration: '10s', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
    checks: ['rate>0.99'],
  },
};

export default function () {
  const response = http.get('http://127.0.0.1:8000/health', {
    timeout: '3s',
  });
  check(response, {
    'status is 200': (r) => r.status === 200,
    'database is ready': (r) => {
      try { return r.json('database') === 'ready'; }
      catch { return false; }
    },
  });
  sleep(1);
}

احفظه باسم performance.js وشغله بـk6 run performance.js بعد فحص المسار يدويًا. عدد المستخدمين الافتراضيين هنا لا يساوي عدد الطلبات في الثانية، لأن الانتظار وزمن الخادم يؤثران في المعدل. وتوضح وثائق العتبات كيف تصبح المقاييس معايير نجاح وفشل للأداة.

نفّذ تدريجيًا ولا تغيّر عدة عوامل معًا

1. تحقق من صحة الاستجابة دون حمل، بما فيه المصادقة والبيانات المطلوبة.
2. ابدأ بحمل منخفض وسجل الأخطاء قبل زيادته.
3. شغّل سيناريو قراءة واقعيًا؛ لا تعمم نتيجة health check على بحث أو إنشاء طلب.
4. راقب الخادم والقاعدة وسجل التوقيت المقابل للتباطؤ.
5. غيّر عاملًا مؤثرًا واحدًا، مثل فهرس مناسب لاستعلام ثبت بطؤه، ثم أعد المقارنة بالشروط نفسها.

طلبات الكتابة تحتاج بيانات اختبار وخطة تنظيف تمنع تضخم القاعدة أو إرسال إشعارات حقيقية. تجنب استخدام حساب واحد لكل حمل إذا كانت المتطلبات تشمل عزل المستخدمين أو قفل سجلات؛ قد يقيس ذلك سيناريو مختلفًا عن الاستخدام المتوقع.

صياغة النتيجة التي يمكن الدفاع عنها

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

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