«مئة مستخدم متزامن» ليست رقمًا قابلًا للاختبار حتى تحدد ماذا يفعل هؤلاء المئة. الاختبار المفيد يقيس أربعة أشياء تحت مزيج عمليات يشبه يوم عملك: زمن الاستجابة لكل عملية بالنسبة المئوية لا بالمتوسط، ونسبة الأخطاء، وتراكم طوابير المعالجة مثل OCR والفهرسة، واستهلاك الموارد على الخوادم وقاعدة البيانات.
واكتب حدود القبول قبل التشغيل لا بعده، ونفّذ الاختبار على بيئة وبيانات قريبة من الإنتاج في الحجم، وإلا فالنتيجة تقيس بيئة لن تعمل عليها أبدًا.
إن كنت ستكتب شرط اختبار الأداء في كراسة الشروط أو خطة القبول، أو تراجع تقرير أداء يقدمه المورد بصفتك مدير تقنية معلومات أو مهندس بنية، فهذه المنهجية لك. تفيدك أكثر إن كان النظام سيُثبت على خوادم جهتك أو في بيئة خاصة، لأن التحجيم عندها يقع عليك أو يُصمم لك. أما إن كنت في بيئة سحابية مشتركة فمعظم ما هنا يصلح أسئلة تطرحها على المورد عن اختباراته هو.
أولًا: عرّف «المتزامن» قبل أن تختبره
ثلاثة معانٍ تُستعمل الكلمة نفسها للدلالة عليها، والفرق بينها قد يبلغ عشرة أضعاف في الحمل الفعلي:
جلسات مفتوحة
مئة موظف سجلوا الدخول وتركوا النظام مفتوحًا في متصفحاتهم. أغلبهم لا يرسل أي طلب في أي لحظة. هذا حمل خفيف على الخادم، وهو ما يقصده معظم الناس حين يقولون «مئة متزامن».
مستخدمون نشطون
مئة موظف يعملون فعلًا خلال نافذة زمنية قصيرة: يبحثون ثم يقرؤون النتيجة ثم يفتحون ملفًا ثم يعتمدون. بين كل عملية وأخرى وقت تفكير. هذا هو المعنى الصحيح لاختبار الأداء.
طلبات متزامنة
مئة طلب تصل إلى الخادم في اللحظة ذاتها بلا وقت تفكير. هذا اختبار إجهاد لا يمثل يوم عمل، ومفيد فقط لمعرفة نقطة الانهيار.
اكتب في الشرط: «مئة مستخدم نشط يؤدون مزيج العمليات المحدد في الملحق، بوقت تفكير متوسطه كذا ثانية بين العمليات». بهذه الجملة يصبح الاختبار قابلًا للتكرار والمقارنة بين الموردين.
إن لم تعرف عدد المتزامنين في الذروة، فاستخرجه من سجلات نظام قائم يستعمله الموظفون أنفسهم، كخادم الملفات أو نظام الاتصالات الإدارية، في أكثر أيام السنة ازدحامًا. التقدير الشائع «عُشر المسجلين» قد يصح وقد يخطئ كثيرًا في جهات فيها فرق أرشيف ومسح تعمل طوال اليوم.
ثانيًا: ابنِ نموذج الحمل من يوم عمل حقيقي
نموذج الحمل هو قائمة العمليات التي سيؤديها المستخدمون الافتراضيون ونسبة كل منها. أخطر خطأ في اختبارات أنظمة الأرشفة أن يُختبر تسجيل الدخول وفتح الصفحة الرئيسية فقط، فيخرج التقرير بأرقام ممتازة لا علاقة لها بالعمل الفعلي. نظام الوثائق يثقل في البحث داخل النص، والمعاينة، والرفع، والمعالجة التي تتبع الرفع.
| العملية | نسبة مقترحة من العمليات | لماذا تهم | ما تقيسه |
|---|---|---|---|
| بحث بكلمة أو عبارة داخل النص | 25% | أكثر عملية تكرارًا وتضغط على الفهرس | زمن ظهور أول صفحة نتائج |
| بحث بالحقول والفلاتر (نوع، تاريخ، جهة) | 15% | تضغط على قاعدة البيانات | زمن الاستجابة مع فلاتر مركبة |
| فتح مستند ومعاينته في المتصفح | 25% | تتضمن تحميل ملف وتوليد أو جلب معاينة | زمن ظهور الصفحة الأولى من المستند |
| تنزيل مستند | 5% | تضغط على التخزين والشبكة | معدل النقل وزمن البدء |
| رفع مستند رقمي مع تعبئة بياناته | 10% | كتابة على التخزين وقاعدة البيانات | زمن الحفظ حتى التأكيد |
| رفع ملف ممسوح يمر على OCR | 5% | يولّد عملًا خلفيًا ثقيلًا | زمن الحفظ، ثم زمن ظهوره في نتائج البحث |
| إجراءات سير العمل (فتح مهمة، اعتماد، رفض) | 10% | تكتب في سجل التدقيق وترسل إشعارات | زمن تنفيذ الإجراء |
| تصفح المجلدات والقوائم | 5% | تكشف بطء الصلاحيات على المجلدات الكبيرة | زمن عرض مجلد بآلاف العناصر |
النسب أعلاه نقطة بداية للنقاش، لا معيار. جهة يغلب عليها المسح والفهرسة سترفع نسبة الرفع، وجهة يغلب عليها الاطلاع سترفع البحث والمعاينة. المهم أن تُكتب النسب وتُعلن في التقرير.
المستخدم الافتراضي يحتاج صلاحيات واقعية
لا تشغّل الاختبار بحساب مشرف واحد مكرر مئة مرة. المشرف يرى كل شيء، فلا يمر النظام بفحص الصلاحيات الذي يحدث مع المستخدم العادي، وهذا الفحص من أثقل ما في البحث داخل أرشيف كبير. وزّع المستخدمين الافتراضيين على أدوار وإدارات مختلفة كما سيكونون في الإنتاج.
ثالثًا: البيانات والبيئة تحددان صدق النتيجة
نظام يستجيب بسرعة وفي فهرسه ألف مستند قد يتصرف بشكل مختلف وفي فهرسه مليون. لذلك اشترط أن يجري الاختبار على:
- حجم بيانات مماثل لما سيكون في النظام بعد الترحيل، عددًا وحجمًا، ولو بمستندات مولّدة أو منسوخة إن تعذر استعمال الحقيقية.
- تركيبة مماثلة: نسبة الممسوح إلى الرقمي، والملفات الكبيرة كالمخططات، واللغتين العربية والإنجليزية.
- بنية مماثلة للإنتاج في عدد الخوادم وتوزيع المكونات، أو بنية أصغر معلنة مع توضيح كيف تُنقل النتيجة إلى الإنتاج.
- شبكة ممثلة: إن كان مستخدمون في الفروع، فشغّل جزءًا من الحمل من موقع فرع أو بمحاكاة زمن تأخر مماثل.
- نفس إعدادات الأمان: التشفير وسجل التدقيق والصلاحيات مفعّلة، لا معطلة لتحسين الأرقام.
اختبار البحث وحده على أرشيف كبير موضوع مستقل له منهجيته، وقد فصّلناه في اختبار البحث في أرشيف كبير باستخدام بيانات مماثلة لبيئتك.
رابعًا: ما الذي تقيسه وكيف تقرأه
زمن الاستجابة بالنسب المئوية
المتوسط يخفي المشكلة. إن كانت تسع عمليات بحث من عشر تستغرق ثانية وواحدة تستغرق عشرين ثانية، فالمتوسط يبدو مقبولًا بينما موظف من كل عشرة يشتكي. اطلب في التقرير الوسيط (p50) والنسبة 95 (p95)، أي الزمن الذي تنتهي قبله 95% من العمليات، لكل نوع عملية على حدة.
نسبة الأخطاء
أي طلب انتهى بخطأ أو انقطاع أو مهلة. ارصد نوع الخطأ لا عدده فقط: خطأ في الرفع أخطر من خطأ في تحميل صورة مصغرة، لأنه قد يعني مستندًا لم يُحفظ.
طوابير المعالجة الخلفية
هذا ما تغفله معظم الاختبارات. المستخدم يرفع ملفًا ممسوحًا ويرى «تم الحفظ» في ثانيتين، لكن النص لا يصبح قابلًا للبحث إلا بعد أن يمر على OCR والفهرسة. قس طول الطابور خلال الاختبار وبعده: هل يتراكم باستمرار؟ وكم يستغرق حتى يفرغ بعد توقف الحمل؟ طابور يتراكم دون توقف يعني أن قدرة المعالجة أقل من معدل الرفع، وستظهر المشكلة بعد أسابيع من الإطلاق لا في يومه.
استهلاك الموارد
المعالج والذاكرة والقرص والشبكة على كل خادم، واتصالات قاعدة البيانات. الغرض ليس الرقم ذاته بل معرفة أي مكوّن يصل إلى حده أولًا، فهو ما سيحتاج توسعة حين ينمو الاستخدام.
قالب حدود القبول (تُملأ قبل التشغيل وتوقّع من الطرفين)
- البحث داخل النص: p95 لا يتجاوز ____ ثانية
- فتح المستند ومعاينة صفحته الأولى: p95 لا يتجاوز ____ ثانية
- حفظ مستند مرفوع حتى التأكيد: p95 لا يتجاوز ____ ثانية لملف حتى ____ ميجابايت
- إجراء سير العمل: p95 لا يتجاوز ____ ثانية
- نسبة الأخطاء الكلية: أقل من ____ %، وصفر أخطاء في حفظ المستندات
- طابور OCR: يفرغ خلال ____ دقيقة بعد توقف الحمل، ولا يتجاوز ____ عنصرًا خلاله
- لا مكوّن يتجاوز ____ % من المعالج أو الذاكرة لمدة أطول من ____ دقائق متصلة
الأرقام تحددها جهتك بحسب ما يحتمله العمل، لا ما يقترحه المورد. ضع موظفًا من الإدارة الأكثر استخدامًا أمام نظام تجريبي، واسأله متى يصبح الانتظار مزعجًا؛ هذا أصدق من أي رقم منقول.
خامسًا: خطة الاختبار خطوة بخطوة
- قياس الأساس نفّذ كل عملية بمستخدم واحد وسجّل أزمنتها. هذا مرجعك لمعرفة أثر الحمل.
- التصعيد التدريجي ارفع المستخدمين النشطين على مراحل (25، 50، 75، 100) مع ثبات كل مرحلة دقائق كافية لاستقرار الأرقام. ارصد المرحلة التي يبدأ فيها p95 بالارتفاع الحاد.
- الحمل المستهدف ثبّت مئة مستخدم نشط بنموذج الحمل الكامل مدة تمثل ساعة ذروة حقيقية على الأقل، وقارن بحدود القبول.
- الحمل الممتد شغّل حملًا أقل من الذروة ساعات طويلة لكشف تسرب الذاكرة وتراكم الطوابير وامتلاء السجلات، وهي مشكلات لا تظهر في اختبار قصير.
- الذروة المفاجئة أضف دفعة كبيرة من الرفع أو الدخول في دقائق قليلة، كما يحدث صباح أول يوم عمل بعد إجازة، وراقب التعافي بعدها.
- الاختبار أثناء الصيانة شغّل حملًا متوسطًا أثناء النسخ الاحتياطي أو إعادة الفهرسة إن كانت ستتزامن مع ساعات عمل في أي فرع.
- التحليل والتكرار حدّد المكوّن الذي بلغ حده، وعدّل، ثم أعد المرحلة المتأثرة فقط وسجّل الفرق.
أخطاء تجعل الاختبار بلا قيمة
- الاختبار على بيئة فارغة: أرقام ممتازة على فهرس صغير لا تقول شيئًا عن الأداء بعد الترحيل.
- ذاكرة التخزين المؤقت تخدع النتائج: البحث عن الكلمة نفسها مئة مرة يُخدم من الذاكرة المؤقتة. نوّع الكلمات والمستندات من قائمة كبيرة.
- مولّد الحمل هو عنق الزجاجة: جهاز الاختبار نفسه قد يعجز عن توليد الحمل فيبدو النظام بطيئًا. راقب موارده أيضًا.
- تجاهل ما بعد الرفع: قياس زمن الحفظ دون متابعة طابور OCR والفهرسة يخفي أهم نقطة ضعف في أنظمة الأرشفة.
- حدود قبول بعد النتائج: إن كُتبت الحدود بعد رؤية الأرقام فستُكتب على مقاس الأرقام.
الجهة: مستشفى خاص يريد نظامًا لوثائقه الإدارية والعقود، بمئة مستخدم نشط في الذروة، منهم 15 في وحدة الأرشيف يرفعون ملفات ممسوحة. الافتراضات: الأرشيف بعد الترحيل نحو 700 ألف مستند، والاختبار على بيئة مطابقة للإنتاج.
ما قد يكشفه الاختبار: أزمنة البحث والمعاينة ضمن الحدود في كل المراحل، لكن طابور OCR يتراكم بثبات في مرحلة المئة مستخدم لأن وحدة الأرشيف ترفع أسرع مما تعالجه الموارد المخصصة، ويحتاج بعد توقف الحمل وقتًا طويلًا ليفرغ.
القرار المترتب: لا تُضاف موارد لطبقة التطبيق لأنها لم تكن المشكلة. بل يُناقش مع المورد فصل المعالجة على موارد مستقلة، أو جدولة جزء منها ليلًا، أو قبول تأخر محدد في ظهور الممسوح في البحث يُكتب كحد قبول. بدون قياس الطابور كان المستشفى سيقبل النظام ثم يكتشف بعد أسابيع أن الملفات الممسوحة «لا تظهر في البحث».
ما تطلبه في تقرير الأداء من المورد
عناصر إلزامية في أي تقرير أداء
- تعريف المستخدم المتزامن المستخدم في الاختبار، ووقت التفكير بين العمليات.
- نموذج الحمل بنسبه، وقائمة العمليات الفعلية المنفذة.
- حجم البيانات في النظام أثناء الاختبار وتركيبتها.
- البنية التي جرى عليها الاختبار ومقارنتها ببنية الإنتاج المقترحة.
- p50 وp95 لكل عملية في كل مرحلة، ونسبة الأخطاء ونوعها.
- سلوك طوابير المعالجة أثناء الحمل وبعده.
- المكوّن الذي بلغ حده أولًا، وما يُقترح عند زيادة المستخدمين.
- أدوات الاختبار ونصوصه، وإمكان إعادة تشغيله من فريق الجهة.
إن كان النظام في بيئة سحابية مشتركة
في البيئة المشتركة لا يُسمح عادة لعميل بتوليد حمل اصطناعي على بنية تخدم غيره، وهذا مفهوم. لكن ذلك لا يعني أن تقبل الأداء على الثقة. غيّر طريقة التحقق بدل أن تتركه:
- اختبار استخدام حقيقي مصغّر: في فترة التجربة، اجمع عشرين إلى ثلاثين موظفًا من إدارات مختلفة في ساعة واحدة ينفذون سيناريوهات محددة مسبقًا على مستندات حقيقية، وسجّل الأزمنة يدويًا أو بأداة قياس في المتصفح.
- اختبار من مواقعك: نفّذ الجلسة من المقر ومن فرع بعيد ومن اتصال جوال، لأن زمن الاستجابة الذي يراه الموظف يتضمن الشبكة لا الخادم وحده.
- مراقبة الطابور بعد الرفع: ارفع دفعة ملفات ممسوحة وسجّل متى تصبح قابلة للبحث.
- التزام تعاقدي: اطلب في اتفاقية الخدمة ما يُقاس من جهة المورد وكيف يُبلَّغ عنه، وما الإجراء إن تدهور الأداء عن مستوى متفق عليه.
هذا لا يعطيك نقطة الانهيار، لكنه يعطيك ما يهمك فعلًا: هل يعمل النظام بسرعة مقبولة لموظفيك في ظروفهم الحقيقية.
اختبار الأداء مع وثيقة
ما يستحق الاختبار تحت الحمل في وثيقة هو ما يستعمله موظفوك يوميًا من قدراته: البحث الفوري داخل محتوى PDF والمستندات الممسوحة، وOCR للعربية والإنجليزية، والرفع الجماعي بالسحب والإفلات وربط الماسح الضوئي، ومسارات الموافقة متعددة المراحل مع إشعاراتها، وسجل التدقيق الذي يرصد كل فتح وتعديل وتنزيل. ويُقدَّم النظام بأربعة نماذج نشر، وفي السحابة الخاصة والنشر على خوادم الجهة والنشر الهجين يُحجَّم النظام لك وحدك، فيصبح اختبار الحمل على بياناتك جزءًا طبيعيًا من القبول.
أما نطاق الاختبار نفسه، أي من يُعد البيئة ومن يشغّل أدوات الحمل وأين يُجرى، وحدود القبول، فتُحدَّد في العرض الفني وخطة التنفيذ بحسب نموذج النشر. ابدأ بعرض توضيحي على عينة من مستنداتك لتختار العمليات الأهم في نموذج الحمل، ثم أدرج الاختبار في معايير قبول النظام قبل توقيع محضر الاستلام.
ما تجهزه قبل طلب العرض
- عرّف المتزامن في جملة واحدة واكتبها في الشرط.
- استخرج نسب العمليات من سجلات نظامك الحالي.
- املأ قالب حدود القبول مع الإدارة الأكثر استخدامًا.
- أرسل نموذج الحمل وحجم الأرشيف مع طلبك عبر صفحة خيارات النشر والبنية ليُبنى عليه اقتراح البنية، وراجع كيف تُشتق مواصفاتها في دليل تحديد متطلبات الخادم قبل التركيب.
حدّد نموذج الاستضافة المناسب لجهتك
سحابة داخل المملكة أم خوادمكم الخاصة؟ أرسل متطلبات الأمن والاتصال والسعة، ونوضح الخيار الأنسب وما يترتب عليه في العرض.
- عدد المستخدمين المتوقع والإدارات المشاركة
- حجم الأرشيف الحالي تقريباً (عدد الملفات أو الصفحات أو الحجم بالجيجابايت) ونسبة الورقي منه
- نموذج الاستضافة المفضل: سحابة داخل المملكة أو خوادم الجهة
- النظام الحالي للملفات والأنظمة المطلوب التكامل معها
الهاتف وواتساب: +966 56 533 0501 — الأحد إلى الخميس 9 صباحاً حتى 6 مساءً.