المستخدمون المتزامنون ونماذج عبء العمل

لماذا يهم

لا يكون لاختبار الحمل معنى إلا بقدر واقعية الحمل الذي يطبّقه. شغّل ⁦1,350⁩ مستخدماً افتراضياً بلا توقف، فسيرسلون آلاف الطلبات في الثانية بدلاً من ⁦90⁩، وقد يفشل النظام في اختبار لا علاقة له بالواقع. وشغّل العدد الصحيح من المستخدمين على الصفحة الرئيسية وحدها، فتجيب ذاكرة التخزين المؤقت (Cache) عن كل شيء، بينما لا تتعرّض رحلة إتمام الشراء (Checkout)، التي تُنشئ طلبات الشراء وتستدعي مزوّد خدمة الدفع، لأي حمل.

وبالنسبة إلى المختبِر، فالنموذج وسيلته لمساءلة المتطلبات وقراءة النتائج: فعبارة «تدعم ⁦2,000⁩ مستخدم» لا يمكن اختبارها حتى يحدد أحدٌ أيّ مستخدمين، يفعلون ماذا، وبأي معدّل.

المستخدمون المتزامنون والطلبات قيد المعالجة والطلبات في الثانية

ثلاثة أرقام يكثر الخلط بينها. المستخدمون المتزامنون لديهم جلسة نشطة خلال الفترة نفسها، سواء أكانوا ينتظرون استجابة الآن أم لا. والطلبات قيد المعالجة (Requests in Flight)، وتسمّى أحياناً الطلبات المتزامنة، هي ما يعالجه الخادم في لحظة واحدة. أما الطلبات في الثانية فمعدّل لوصول الطلبات أو اكتمالها؛ ومعدّل الاكتمال هو الإنتاجية (Throughput)، وهو يساوي معدّل الوصول ما دام النظام يواكب الحمل.

وتضيف أدوات الحمل مصطلحاً رابعاً: المستخدم الافتراضي (Virtual User, VU)، وهو نسخة عاملة من سكربت الاختبار تؤدي دور مستخدم واحد. فالمستخدم الافتراضي الذي يتوقف كما يتوقف الإنسان يعادل مستخدماً متزامناً واحداً، أما الذي لا يتوقف فيُنتج حركة أشخاص كثيرين. وبعض الفرق تقول «المستخدمون المتزامنون» وتقصد الطلبات قيد المعالجة، فاسأل أيّهما يقصد المتطلب.

مكوّنات نموذج عبء العمل

يصف نموذج عبء العمل الحمل الذي يجب أن يطبّقه الاختبار ليشبه بيئة الإنتاج. ويسمّي منهج ISTQB لاختبار الأداء نمطَ ما يفعله المستخدمون الملفَّ التشغيلي (Operational Profile)؛ أما ملف الحمل (Load Profile) فيحدد كم مستخدماً افتراضياً ينفّذ أيّ ملفات تشغيلية خلال فترة زمنية، مثل تصاعد تدريجي (Ramp-up) تليه حالة مستقرة (Steady State). ابنِ النموذج من أدلة: التحليلات أو سجلات الوصول أو بيانات المراقبة أو توقعات الأعمال.

وقرّر أيضاً كيف يُولَّد الحمل. في النموذج المغلق (Closed Model) يدور عدد ثابت من المستخدمين الافتراضيين في رحلاتهم، ولا يرسل كلٌّ منهم طلبه التالي إلا بعد انتهاء السابق، فإذا تباطأ النظام تلقّى طلبات أقل وخفّف الاختبار حمله من تلقاء نفسه. وفي النموذج المفتوح (Open Model) يصل المستخدمون بمعدّل محدد مهما كان زمن الاستجابة، فإذا تباطأ النظام تراكم العمل. وفي k6 يمثّل constant-vus نموذجاً مغلقاً وconstant-arrival-rate نموذجاً مفتوحاً. استخدم النموذج المفتوح للمواقع والواجهات البرمجية العامة، والمغلق لمجموعة ثابتة مثل ⁦200⁩ موظف في مركز اتصال.

• الرحلات: رحلات المستخدم المهمة، مثل البحث وإتمام الشراء، وكل رحلة سلسلة من الطلبات.
• المزيج: نصيب كل رحلة من الجلسات، مثلاً ⁦50%⁩ تصفّح و⁦15%⁩ إتمام شراء.
• المعدّل: عدد الجلسات التي تبدأ في الثانية خلال الفترة المختبَرة، وهي عادةً ساعة الذروة.
• البيانات: ما يكفي من المستخدمين والمنتجات وعبارات البحث المختلفة لتتصرّف ذاكرة التخزين المؤقت كما في الإنتاج.

جرّبها: مولّد بيانات اختبار الأداء جرّبها: مولّد بيانات اختبار التحميل

زمن التفكير والإيقاع

زمن التفكير هو التوقف الذي يأخذه المستخدم الحقيقي بين خطوتين من رحلته: قراءة صفحة، أو كتابة عنوان. ومكانه في السكربت بين الطلبات. خذه من التحليلات (الوقت المستغرق في الصفحة) وغيّره عشوائياً، مثلاً بين ⁦15⁩ و⁦24⁩ ثانية بدلاً من ⁦19.5⁩ ثانية ثابتة، حتى لا يتحرك المستخدمون الافتراضيون بخطى متطابقة فتصل طلباتهم إلى الخادم في موجات. يضيفه JMeter بمؤقّتات مثل المؤقّت العشوائي المنتظم (Uniform Random Timer)، ويضيفه k6 باستدعاء sleep().

الإيقاع هو الفاصل بين بداية تكرار (Iteration) واحد، أي رحلة كاملة، وبداية التكرار التالي للمستخدم الافتراضي نفسه. فمع إيقاع ⁦300⁩ ثانية ورحلة تستغرق ⁦240⁩ ثانية ينتظر المستخدم الافتراضي ⁦60⁩ ثانية، فيبدأ عملية إتمام شراء واحدة كل خمس دقائق. وإذا تباطأ النظام فاستغرقت الرحلة أكثر من ⁦300⁩ ثانية فات المعدّل المخطط، وهذا في حدّ ذاته نتيجة تستحق التسجيل.

One virtual user, checkout journey: 12 requests, pacing 300 s
Each step: ~0.5 s response + think time, random 15-24 s (mean 19.5 s)

   time  what the virtual user does
    0 s  request 1: view cart, then think
   20 s  request 2: enter address, then think
    ...  requests 3 to 11, about 20 s apart
  220 s  request 12: confirm payment, then think
  240 s  journey done, wait 60 s for the next pacing slot
  300 s  iteration 2 starts: request 1: view cart

Think time = pause between requests inside one journey
Pacing     = start of one journey to start of the next

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

قانون ليتل: المستخدمون والمعدّلات والزمن

ينص قانون ليتل على أن متوسط عدد العناصر داخل نظام مستقر يساوي متوسط معدّل وصولها مضروباً في متوسط الزمن الذي يقضيه كل عنصر داخله: L = λ × W. وهو ينطبق على طابور أمام صندوق متجر، وعلى خادم، وعلى موقع كامل، أياً كان نمط الوصول. واحرص على اتساق الوحدات: طلبات في الثانية مع ثوانٍ.

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

• الخادم: الطلبات قيد المعالجة = الطلبات في الثانية × متوسط زمن الاستجابة: ⁦90 × 0.5 = 45⁩.
• المستخدمون: المستخدمون المتزامنون = الجلسات التي تبدأ في الثانية × متوسط مدة الجلسة؛ ففي متجر المثال التطبيقي أدناه: ⁦10 × 135 = 1,350⁩.
• السكربت: المستخدمون الافتراضيون = الطلبات المستهدفة في الثانية × (زمن الاستجابة + زمن التفكير لكل طلب): ⁦90 × 15 = 1,350⁩؛ ودون زمن تفكير يكفي ⁦90 × 0.5 = 45⁩ مستخدماً افتراضياً لإرسال المعدّل نفسه (⁦90⁩ طلباً في الثانية). ويكتب منهج ISTQB لاختبار الأداء هذه العلاقة بالصيغة: الإنتاجية = المستخدمون الافتراضيون / (زمن المعالجة + زمن التفكير).
• فحص التقرير: ⁦200⁩ مستخدم افتراضي باستجابات ⁦0.4⁩ ثانية وزمن تفكير ⁦5⁩ ثوانٍ يُنتجون نحو ⁦200 / 5.4 ≈ 37⁩ طلباً في الثانية. فإن أظهر التقرير ⁦150⁩ طلباً في الثانية، فكل مستخدم افتراضي لم يقضِ إلا نحو ⁦200 / 150 ≈ 1.3⁩ ثانية لكل طلب، أي إن معظم زمن التفكير المخطط لم يُطبَّق.
• الحدود: استخدم متوسطات على فترة مستقرة، لا p95 ولا طابوراً ما زال ينمو.

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

مثال تطبيقي: من التحليلات إلى نموذج عبء العمل

يستعد متجر إلكتروني لأمسية تخفيضات. شهدت أكثر ساعة ازدحاماً في العام الماضي ⁦36,000⁩ جلسة، أي ⁦10⁩ جلسات في الثانية، على أربع رحلات. ولكل رحلة تعطي التحليلات نصيبها من الجلسات، والطلبات لكل جلسة، ومتوسط الزمن لكل خطوة (الاستجابة مع زمن التفكير).

الطلبات في الثانية لرحلة ما = الجلسات في الثانية × نصيبها × الطلبات لكل جلسة، ومستخدموها المتزامنون = طلباتها في الثانية × الزمن لكل خطوة، وهذا هو قانون ليتل. والمجموع ⁦90⁩ طلباً في الثانية و⁦1,350⁩ مستخدماً متزامناً. فإتمام الشراء ⁦15%⁩ من الجلسات لكنه ⁦20%⁩ من الطلبات، لأن جلسته تضم أكثر الطلبات، و⁦27%⁩ من المستخدمين، لأن الناس يقضون أطول وقت في كل خطوة من خطواته؛ والاختبار الذي يتجاهل المزيج يضع حملاً أقل من اللازم تحديداً على الجلسات واستدعاءات الدفع الأهم.

Peak hour: 36,000 sessions / 3,600 s = 10 new sessions per second

journey           share  requests  s/step  requests per second  concurrent users
browse catalogue   50%       8       15    10 × 0.50 × 8  = 40    40 × 15 =   600
search, compare    30%      10       12    10 × 0.30 × 10 = 30    30 × 12 =   360
checkout           15%      12       20    10 × 0.15 × 12 = 18    18 × 20 =   360
track an order      5%       4       15    10 × 0.05 × 4  =  2     2 × 15 =    30
total             100%   9 avg   15 avg                   = 90              1,350

requests = requests per session; s/step = response + think time per request
avg = weighted: 90 / 10 = 9 requests per session; 1,350 / 90 = 15 s per request
average session duration = 9 × 15 = 135 s; 10 sessions/s × 135 s = 1,350 users
In flight on the server at 0.5 s average response: 90 × 0.5 = 45 requests

جرّبها: مولّد بيانات اختبار الأداء

أسئلة شائعة

المراجع

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Grafana k6 documentationGrafana Labsالتوثيق الرسمي لأداة Grafana k6، وهي أداة مفتوحة المصدر وقابلة للتوسعة لاختبار الحمل والأداء.
• Apache JMeter User's ManualApache Software Foundationكيف تُبنى اختبارات الحمل وتُعامَل بالمعاملات وتُشغَّل في JMeter، وكيف تُقرأ مستمعاته وتقاريره.