الذروة تاريخ محدد، والاستعداد كذلك
يقع بلاك فرايداي في اليوم التالي لعيد الشكر (Thanksgiving)، الذي يحدده القانون الفيدرالي الأمريكي في الخميس الرابع من نوفمبر. وهذا يعطي في 2026 يوم الخميس 26 نوفمبر لعيد الشكر، والجمعة 27 نوفمبر لبلاك فرايداي، والاثنين 30 نوفمبر لسايبر مونداي. هذه التواريخ محسوبة من تلك القاعدة، فقارنها بالتقويم التجاري لسوقك، فقد يبكّر عروضه أو يمدّدها.
تبقّى أربعة أسابيع عند تاريخ هذا المقال. وهي كافية للتجميد والقياس والتصحيح، لا لإعادة البناء كله. فالهدف ليس امتلاك أكبر خادم ممكن، بل معرفة حدّ خادمك قبل أن يكتشفه الزوار نيابة عنك، ثم تقرير ما ستفعله مسبقًا إذا بلغته.
ما الذي يُسقط المتجر في أثناء الذروة
- تخزين مؤقت لا يخدم إلا الزوار المجهولين — بمجرد وجود ملف تعريف ارتباط للسلة أو الجلسة، تُعاد معالجة الصفحة عبر PHP وقاعدة البيانات عند كل طلب.
- استعلامات SQL محتملة عند الحركة الخفيفة — الاستعلام البطيء لا يزعج أحدًا مع خمسة زوار. ومع مئتي زائر في آن واحد يحتجز الاتصالات ويُبطئ كل الطلبات التالية.
- عمليات PHP أكثر مما تتحمله الذاكرة المتاحة — كل عملية تستهلك جزءًا من الذاكرة.
- تغيير في اللحظة الأخيرة — إضافة أو قالب أو رمز ترويجي مضبوط بشكل خاطئ يُدفع قبل يوم. هذا أكثر الأسباب قابلية للتجنب، والتجميد يزيله.
- خدمة طرف ثالث تُستدعى عند كل عرض صفحة — وحدة شحن أو تقييمات أو ولاء تُستعلم بشكل متزامن. إذا تباطأت تباطأ المتجر معها، وإن لم يكن خادمك هو السبب.
- غياب تعليمات مكتوبة — لا أحد يعرف من يقرر إيقاف ميزة، وعند أي عتبة، ومن يُبلغ العميل. فيرتجل الجميع أثناء العطل، فيطول.
تجميد التغييرات: أربعة أسابيع وتاريخ قطع واحد
التجميد أرخص الإجراءات وأكثرها فعالية: ما دامت الشيفرة والإعدادات ثابتة، تبقى قياساتك صحيحة. اختر تاريخ قطع، مثل الجمعة 20 نوفمبر، قبل الذروة بأسبوع. بعده لا تحديث للنظام، ولا إضافة جديدة، ولا تغيير للقالب. لا يمرّ إلا تصحيح الأخطاء الحرجة، بعد تجربته على النسخة وتدوينه في سجل.
لا يشمل التجميد التحديثات التلقائية، فأوقفها طوال الفترة. ويمكن إعادة الجدول التالي كل سنة بتغيير التواريخ.
خذ نسخة احتياطية كاملة قبل التجميد مباشرة (الملفات وقاعدة البيانات وإعدادات الخادم)، ثم استعدها مرة على النسخة وقِس المدة: هذه المدة معطًى في الخطة البديلة. ويشرح لقطة VPS أم نسخة احتياطية الفرق بين اللقطة والنسخة الاحتياطية.
جدول الاستعداد الذي يُعاد كل سنة
مرّر الجدول أفقيًا
| الفترة | ما يُنجَز | الدليل المنتظر |
|---|---|---|
| حتى 6 نوفمبر | جرد: إصدار النظام، الإضافات، خدمات الأطراف الثالثة، المهام المجدولة، باقة الاستضافة | جدول مؤرَّخ، مع مسؤول واحد لكل سطر |
| من 9 إلى 13 نوفمبر | نسخة من المتجر واختبار حمل مرجعي | نتيجة محفوظة مع الأمر الدقيق والسيناريو |
| من 16 إلى 19 نوفمبر | ضبط التخزين المؤقت وقاعدة البيانات وPHP، ثم اختبار جديد | السيناريو نفسه والمعاملات نفسها ونتائج مقارنة |
| الجمعة 20 نوفمبر | تجميد التغييرات ونسخة احتياطية كاملة | استعادة مجرَّبة، لا مجرد نسخة مأخوذة |
| من 21 إلى 26 نوفمبر | تصحيحات حرجة فقط، بعد تجربتها على النسخة | سجل تغييرات محدَّث |
| من 27 إلى 30 نوفمبر | مراقبة الذروة وخطة بديلة جاهزة للتنفيذ | تنبيهات مفعّلة وشخص مناوب معيَّن |
القياس على نسخة باستخدام k6 وab
تجهيز نسخة من المتجر
لا تختبر المتجر المباشر أبدًا: قد يُسقطه اختبار الحمل، ويلوّث إحصاءاتك، ويُنشئ طلبات وهمية. استعد نسخة احتياطية على خادم افتراضي أو استضافة اختبار من النوع نفسه كالإنتاج، بإصدار PHP نفسه وقاعدة البيانات نفسها. أخفِ هويات العملاء، وأوقف إرسال البريد، وضع وحدات الدفع في وضع التجربة.
كتابة السيناريو قبل اختيار الأداة
دوّن رحلة المشتري: الصفحة الرئيسية، صفحة الفئة، صفحة المنتج، الإضافة إلى السلة، صفحة السلة، ثم بداية إتمام الطلب. حدّد وزن كل خطوة، كأن تكثر صفحات المنتج ويقل الدفع. السيناريو المقتصر على الصفحة الرئيسية يقيس التخزين المؤقت لا المتجر.
تثبيت k6
k6 أداة اختبار حمل مفتوحة المصدر من Grafana، وهي ملف تنفيذي واحد. اتبع خطوات التثبيت في التوثيق الرسمي لـ k6 على الجهاز الذي يولّد الحمل، لا على الخادم المختبَر أبدًا، ثم تحقق بالأمر
k6 version.كتابة السكريبت على نموذج صعود تدريجي
في ملف اسمه
charge.js، استوردhttpمنk6/httpوcheckمنk6. عرّف سيناريو بالمنفّذexecutor: 'ramping-arrival-rate'(توثيق k6): فهو يحدد عدد التكرارات في الثانية بصرف النظر عن سرعة استجابة الموقع، وهذا أقرب إلى وصول الزوار من عدد ثابت من المستخدمين الافتراضيين. املأstartRateوtimeUnitوpreAllocatedVUsوmaxVUsوstagesتصعد على درجات. وفي الدالة الافتراضية، اجمعhttp.getعلى صفحة المنتج ثمhttp.postعلى الإضافة إلى السلة، معcheckعلى الرمز 200.وضع عتبات تُفشل الاختبار
أضف
thresholdsإلى الخيارات:http_req_failed: ['rate<0.01']وhttp_req_duration: ['p(95)<800']. القيم قيمك أنت، تُحدَّد بحسب ما يتحمله عملاؤك، لا بحسب رقم منقول. إن لم تتحقق عتبة أنهى k6 التنفيذ برمز خروج غير صفري، فيمكن إعادة الاختبار ضمن روتين آلي. لاحظ أنcheckلا تفعل ذلك: العتبات وحدها تُفشل الاختبار.تشغيل الاختبار ومراقبة الخادم في الوقت نفسه
نفّذ
k6 run -e BASE_URL=https://copy.your-domain.com charge.js. في جلسة SSH على الخادم المختبَر، اتركtopأوhtopيعمل وراقبfree -mللذاكرة والتبديل. دوّن في أي درجة من الصعود تقفز أزمنة الاستجابة، وأي مورد يتشبع أولًا: المعالج أم الذاكرة أم اتصالات قاعدة البيانات أم القرص.استكمال الاختبار باختبار سريع بأداة ab
تفحص ApacheBench صفحة بعينها في سطر واحد:
ab -n 500 -c 20 -k https://copy.your-domain.com/product/example/. يحدد الخيار-nالعدد الكلي للطلبات، و-cعدد الطلبات المتزامنة، و-kيفعّل الاتصال الدائم. ينص توثيق Apache على أن الأداة لا تنفّذ HTTP/1.x بالكامل، فاستخدمها للمقارنة قبل ضبط ما وبعده، لا لقياس سعة.إعادة الاختبار نفسه بعد كل ضبط
غيّر شيئًا واحدًا في كل مرة: التخزين المؤقت، عدد عمليات PHP، فهرس في قاعدة البيانات. أعد تشغيل الأمر نفسه تمامًا واحفظ النتائج في ملف مؤرَّخ.
قراءة النتيجة: الذروة لا المتوسط
يُخفي متوسط زمن الاستجابة ما يعيشه المشتري سيئ الحظ. اقرأ الشريحة المئوية 95، أو 99 لأبطأ الحالات، ومعدل الأخطاء. المتجر الذي يبقى متوسطه مقبولًا بينما ينتظر مشترٍ من كل عشرين عدة ثوانٍ يخسر سلالًا دون أن يظهر ذلك في المتوسط.
انظر أيضًا إلى شكل المنحنى. أما الزمن المستقر الذي يتبعه انهيار مفاجئ فيدل على حدّ صلب، مثل أقصى عدد لاتصالات قاعدة البيانات أو لعمليات PHP. هذا الاختبار لا يخبرك بعدد زوارك الفعليين: إنه يخبرك بأي معدل وصول تبدأ نسختك في التراجع، في ظروف الاختبار.
لا تُنشر هنا أي نتيجة رقمية، وذلك مقصود: رقم مقيس على جهاز اختبار لا يقول شيئًا عن جهازك، وقد نُفِّذ السكريبت أعلاه على هدف وهمي فقط للتحقق من صياغته، وهذا لا يثبت أي سعة. القياس الوحيد الذي يُعتد به هو ما تأخذه أنت على نسختك.
أعراض أثناء الاختبار ومسارات المتابعة
مرّر الجدول أفقيًا
| ما تلاحظه | السبب المحتمل | ما يجب قياسه |
|---|---|---|
| زمن استجابة يرتفع مع الحمل ومعالج في أقصاه | صفحات كثيرة تُحسب عبر PHP بدل أن تُقدَّم من التخزين المؤقت | نسبة الصفحات المقدَّمة من التخزين المؤقت للزوار المجهولين |
| ذاكرة ممتلئة ثم استخدام التبديل | عمليات PHP أكثر مما تتحمله الذاكرة المتاحة | الذاكرة لكل عملية PHP وعدد العمليات المسموح بها |
| أخطاء 502 أو 504 على دفعات | كل عمليات PHP مشغولة أو طابور متشبع | ضبط مجمّع PHP ومدة أبطأ الطلبات |
| معالج هادئ وزمن استجابة مرتفع | انتظار قاعدة البيانات أو خدمة طرف ثالث | سجل الاستعلامات البطيئة ومدة الاستدعاءات الخارجية |
| خطأ "too many connections" | بلوغ حد اتصالات قاعدة البيانات | قيمة `max_connections` والاتصالات المستخدمة فعلًا |
| صفحات منتج سريعة وسلة بطيئة | السلة تتجاوز التخزين المؤقت كما ينبغي، وتثقل القاعدة | الاستعلامات التي تطلقها الإضافة إلى السلة |
التخزين المؤقت: ما يُقدَّم بسرعة وما لا يُخزَّن أبدًا
توثيق WooCommerce واضح: صفحات السلة والدفع والحساب يجب أن تبقى ديناميكية لأنها تعرض معلومات خاصة بالعميل. استثنِها من كل تخزين مؤقت، على مستوى الإضافة والخادم وشبكة التوزيع، وتحقق من ملفات تعريف ارتباط الجلسة والسلة التي يستخدمها إصدارك. صفحة سلة خُزّنت بالخطأ تعرض سلة مشترٍ آخر، وهذا أسوأ من العطل.
أما الباقي فاحصر ما يمكن تقديمه كما هو: الصفحة الرئيسية والفئات وصفحات المنتج للزوار الذين لا يحملون ملفات تعريف ارتباط. وتفاصيل المسارات التي تُستثنى على مستوى شبكة التوزيع في دليلنا عن Cloudflare والتخزين المؤقت لموقع عميل. وفي PrestaShop يوصي توثيق المطورين بتفعيل ذاكرة Smarty المؤقتة في صفحة الأداء، وبعدم تفعيل قسم التخزين المؤقت حين تعمل MySQL أو MariaDB على الجهاز نفسه. تحقق من هذه الإعدادات في لوحة إدارة إصدارك، ثم أعد الاختبار بعد كل تعديل.
قاعدة البيانات وذاكرة الكائنات المؤقتة
فعّل سجل الاستعلامات البطيئة في MariaDB قبل الاختبار: SET GLOBAL slow_query_log=1; ثم SET GLOBAL long_query_time=1; لعتبة ثانية واحدة، وهي قيمة عليك ضبطها. تزول هذه الإعدادات الفورية عند إعادة التشغيل، ولحفظها ضعها في ملف الإعدادات. ابتداءً من MariaDB 10.11 أُعيدت تسمية المتغيرات بالبادئة log_slow_، فتحقق من الاسم المستخدم في إصدارك.
تخفف ذاكرة الكائنات المؤقتة مثل Redis الحمل عن القاعدة بإبقاء النتائج المتكررة في الذاكرة. ضع لها حدًا بـmaxmemory واختر سياسة الإخلاء بـmaxmemory-policy: يذكر توثيق Redis أن allkeys-lru خيار افتراضي جيد حين يُقرأ جزء من المفاتيح أكثر بكثير من الباقي، بينما يُرجع noeviction خطأً عند امتلاء الذاكرة. راقب keyspace_hits وkeyspace_misses في INFO stats أثناء الاختبار: معدل إصابة منخفض يدل على تخزين مؤقت لا يفيد.
حمِّل ما تملكه فقط
وجّه الاختبار إلى نسختك، لا إلى بوابة الدفع ولا خدمة شحن ولا واجهة برمجية لطرف ثالث: ستُغرقها الأداة بالطلبات وقد يُحظر حسابك. وإن كان سيناريوك يمر بالدفع فاستخدم وضع التجربة لدى المزوّد وبموافقته.
تحديد الحجم: فرضية تتحقق منها بالقياس
إذا كشف الاختبار أن النسخة تتشبع مبكرًا، فأمامك طريقان: إصلاح البرمجيات أو تغيير الباقة. وإن بقي الجهاز هو العامل المحدِّد، فزد الذاكرة أو الأنوية على درجات وأعد الاختبار نفسه بعد كل درجة، حتى يصمد المنحنى بهامش تراه كافيًا.
توصية الموارد المقروءة في موقع، ومنه هذا، تبقى فرضية: لا يُعتد إلا بقياسك على متجرك. وطريقة قراءة الاستهلاك مفصلة في تحديد حجم VPS لموقع عميل. وحين لا يكفي جهاز واحد، يوزّع HAProxy على VPS الحمل، بثمن بنية أكثر تعقيدًا.
إن لم تُجرِ هذا الاختبار بنفسك
يوكل كثير من التجار متاجرهم إلى وكالة أو مزوّد استضافة. ويبقى الاختبار لازمًا: عليك أن تطلبه. اطلب كتابةً ثلاثة أشياء قبل تاريخ التجميد: نتيجة مؤرَّخة لاختبار حمل على نسخة، مع السيناريو وزمن الاستجابة عند الشريحة المئوية 95 المقروء عند الذروة؛ وقائمة التغييرات المزمعة وتاريخ التجميد المتفق عليه؛ وخطة بديلة موقّعة تسمّي الشخص المخوَّل بإيقاف الميزات أو استعادة النسخة الاحتياطية. تقرير يكتفي بالمتوسط، أو عبارة 'كل شيء جاهز' بلا نتيجة، لا يجيب عن الطلب.
قرّر معهم أيضًا من يحسم يوم الذروة: فالخطة البديلة تكلّف ميزات، أي مبيعات، وهذا القرار يعود إلى النشاط التجاري لا إلى المزوّد التقني وحده.
الخطة البديلة: سطر لكل قرار
- من يقرر — شخص معيَّن، له بديل، مخوَّل بتفعيل الخطة دون الرجوع إلى لجنة.
- عند أي عتبة — مثل معدل أخطاء أو زمن استجابة حددتهما أثناء الاختبارات، تقرؤهما المراقبة لا العين.
- إجراء التخفيف — إيقاف الميزات غير الأساسية: توصيات المنتجات والتقييمات والبحث التنبؤي والإضافات الثقيلة التي جُرّبت واحدة واحدة أثناء التجربة.
- الإجراء الثاني — تفعيل صفحة طابور أو صيانة واضحة مع وقت العودة المتوقع بدل خطأ خام.
- الملاذ الأخير — استعادة النسخة السابقة للتجميد، بزمن الاستعادة الذي قستَه وبموافقة من يقرر.
- من يُبلغ — العميل، وفريق التسويق الذي يدفع الحملة، ومزوّد الاستضافة، برسالة مكتوبة مسبقًا.
بعد الذروة: احتفظ بالقياس للعام القادم
احتفظ بالسكريبت والأمر والنتائج وسجل التغييرات في مجلد مؤرَّخ. في العام القادم ستعيد الاختبار نفسه على الإصدار الجديد من المتجر، وستُظهر المقارنة ما إذا كانت الإضافات التي أُضيفت خلال السنة قد أثقلت الرحلة.
ولمتابعة توفر المتاجر خلال الفترة راجع تقرير توفر مواقع العملاء.
