كم زائرًا متزامنًا يتحمّل VPS؟ اختبار حِمل حقيقي حتى نقطة الانهيار

«خادمي يكفي كم زائر؟» — أكثر سؤال يطرحه من يشتري VPS، وأقلّه إجابةً بأرقام. معظم الصفحات تعطيك مواصفات (vCPU وRAM) دون أن تترجمها إلى ما يهمّك فعلًا: كم زائرًا متزامنًا يصمد قبل أن يتباطأ موقعك أو ينهار؟ في هذا الدليل نجيب بالقياس لا بالتقدير: نرفع الحِمل على خادم VPS تدريجيًّا — 5، 10، 25، 50، 100، وصولًا إلى 1000 طلب متزامن — ونرصد بالضبط متى يبدأ الفشل. النتيجة تكشف حقيقة مهمّة عن VPS Concurrent Users: نفس الخادم يتحمّل ~10 طلبات متزامنة فقط بلا كاش، وأكثر من 1000 مع الكاش — كلها أرقام حقيقية مقيسة على خادم مرام.

ماذا تعني «الطلبات المتزامنة»؟

قبل الأرقام، لنوضّح المصطلح. «الطلب المتزامن» (Concurrency) هو عملية نشطة في اللحظة نفسها تشغّل خادمك فعليًّا — مثل بناء صفحة ووردبريس. وهذا يختلف عن «الزائر الفعلي» الذي يُحمّل صفحة في ثانية ثمّ يقرأ دقائق قبل الطلب التالي:

النتيجة العملية: خادم يخدم N طلبًا متزامنًا مستقرًّا يستوعب آلاف الزوّار الفعليين يوميًّا، لأن كل زائر يشغل الخادم لحظات قصيرة فقط. لهذا نقيس السقف بالتزامن — فهو ما يكشف نقطة الانهيار الحقيقية وقت الذروة، لا متوسّط الزيارات.

كيف اختبرنا؟ منهجية الحِمل المتصاعد

ثبّتنا موقع ووردبريس نظيفًا على أحد خوادم مرام، ورفعنا عليه الحِمل بمستويات تزامن متصاعدة، وقِسنا في كل مستوى: الإنتاجية (طلب/ث)، وزمن الاستجابة، ونسبة الفشل — مرّتين: مرّة بصفحات ديناميكية (بلا كاش) ومرّة بكاش الصفحات:

• البيئة: خادم Intel Xeon بأربع أنوية و8GB، Nginx، PHP 8.4، MySQL 8 — بيئة VPS نموذجية.
• الأداة: ApacheBench بمستويات تزامن 5 و10 و25 و50 و100 (ديناميكي)، و50 حتى 1000 (مكاش).
• المقاييس: طلب/ث، ومتوسّط الزمن، وp95 (زمن استجابة 95% من الطلبات)، ونسبة الفشل.
• معيار «الصحّة»: نعتبر الخادم صحّيًّا ما دام p95 دون الثانية وبلا فشل — وهو حدّ تجربة مستخدم مقبولة.

خادم ديناميكي: نقطة الانهيار المبكرة

حين تكون الصفحات ديناميكية (كل طلب يشغّل PHP وقاعدة البيانات)، ظهرت نقطة الانهيار مبكرًا وبوضوح:

• 5 متزامن: 12 طلب/ث، p95 = 539ms — صحّي.
• 10 متزامن: 11.8 طلب/ث، p95 = 960ms — على الحافّة (اقترب من الثانية).
• 25 متزامن: 10 طلب/ث، لكن p95 قفز إلى 2,990ms — تدهور واضح.
• 50 متزامن: p95 = 4,730ms (زمن انتظار ~5 ثوانٍ) — تجربة سيّئة.
• 100 متزامن: انهيار — الإنتاجية هبطت إلى 6.5 طلب/ث وزمن الاستجابة قفز إلى ~15 ثانية.

الدرس: خادم بأربع أنوية يشغّل ووردبريس ديناميكيًّا يظلّ صحّيًّا حتى ~10 طلبات متزامنة فقط. السبب أن كل طلب يستهلك ~ثلث ثانية من زمن المعالج، فبأربع أنوية يكون السقف نحو 12 طلبًا في الثانية — وأي تزامن أعلى يصطفّ في طابور ينفجر معه زمن الانتظار.

ملاحظة: لاحظ أن الإنتاجية لم ترتفع مع زيادة التزامن — بل ثبتت ثمّ انهارت. هذا سلوك نظام مقيّد بالمعالج: إضافة طلبات لا تزيد الطاقة، بل تُطيل الطابور فقط.

خادم مكاش: السقف يقفز ×100

ثمّ فعّلنا كاش الصفحات (FastCGI Cache) على Nginx — الذي يخدم HTML جاهزًا دون تشغيل PHP — وأعدنا الاختبار حتى 1000 متزامن. النتيجة مختلفة جذريًّا:

• 50 متزامن: 8,114 طلب/ث، p95 = 7ms.
• 100 متزامن: 8,051 طلب/ث، p95 = 13ms.
• 200 متزامن: 8,317 طلب/ث، p95 = 28ms.
• 500 متزامن: 7,968 طلب/ث، p95 = 76ms.
• 1000 متزامن: 7,858 طلب/ث، p95 = 141ms فقط — وصفر طلبات فاشلة.

مع الكاش، بقي الخادم مستقرًّا تمامًا حتى 1000 طلب متزامن بزمن استجابة ممتاز — أي أن الكاش نقل سقف السعة من ~10 إلى أكثر من 1000 متزامن على العتاد نفسه (تحسّن ~100 ضعف). لأن الطلبات المكاشة يخدمها Nginx مباشرةً من الذاكرة بلا عنق المعالج.

هذا يفسّر لماذا يركّز دليل تسريع ووردبريس على VPS على كاش الصفحات كأكبر رافعة — فهو لا يسرّع الاستجابة فحسب، بل يضاعف السعة القصوى.

جدول VPS Concurrent Users الكامل بالأرقام

هذا الجدول يجمع القياسين جنبًا إلى جنب — مرجعك السريع لسعة VPS Concurrent Users:

خلاصة الجدول: بلا كاش السقف الصحّي ~10 متزامن، ومع الكاش 1000+ — بنفس المعالج والذاكرة. الفرق كلّه في الإعداد لا العتاد.

كم زائرًا فعليًّا يعني ذلك؟

لنترجم التزامن إلى زوّار حقيقيين. بما أن الزائر يشغل الخادم ~ثانية واحدة من زيارة تمتدّ دقائق، فإن كل طلب متزامن مستقرّ يقابل عددًا أكبر بكثير من الزيارات اليومية:

• خادم ديناميكي (~10 متزامن): يكفي حركة هادئة إلى متوسّطة (آلاف الزيارات اليومية الموزّعة)، لكنه ينهار وقت الذروة أو عند موجة مفاجئة (منشور فيروسي، حملة، هجمة).
• خادم مكاش (1000+ متزامن): يخدم عشرات آلاف الزيارات يوميًّا ويصمد أمام موجات الذروة المفاجئة دون تباطؤ.

🤝 من واقع مرام: هذه أرقام مقيسة فعليًّا على خادم مرام (Xeon، 4 أنوية، ApacheBench، صفر فشل) — لا أرقام مفترضة. الرسالة الأهمّ للأعمال: لا تسأل «كم زائر يتحمّل خادمي؟» بمعزل عن الإعداد. خادم متوسّط مع كاش صحيح يتفوّق على خادم أقوى بلا كاش. الأهمّ أن تصمد وقت الذروة — لأن الزيارة التي تخسرها لحظة الانهيار هي غالبًا أهمّ زيارة.

ما الذي يحدّد VPS Concurrent Users؟

سعة التزامن ليست رقمًا واحدًا بل حصيلة عوامل. لرفع سقف خادمك:

• كاش الصفحات: العامل الأكبر — يتخطّى PHP وقاعدة البيانات (×100 كما رأينا).
• عدد الأنوية (vCPU): يحدّد الطاقة الديناميكية القصوى (ما لا يُكاش: السلّة، الدفع، لوحة التحكّم).
• الذاكرة (RAM): تكفي لتشغيل عمّال PHP والكاش معًا دون تبديل (swap) يقتل الأداء.
• سرعة القرص (NVMe): تقصّر زمن استعلامات قاعدة البيانات وبناء الكاش — راجع لماذا تبطؤ قاعدة البيانات.
• ضبط PHP-FPM: عدد العمّال (pm.max_children) المناسب لذاكرتك يمنع الاختناق أو الإفراط.

ولمعالجة القمم التي تتجاوز خادمًا واحدًا، يأتي التوسّع الأفقي كما في متى تبدأ Horizontal Scaling.

كيف تختبر خادمك بنفسك؟

لا تثق برقم دون قياس. اختبر سعة خادمك بنفسك بأداة بسيطة مثل ApacheBench أو bombardier أو k6:

# ثبّت الأداة
sudo apt install -y apache2-utils

# ارفع التزامن تدريجيًا وراقب p95 والفشل
ab -t 15 -c 10  -k https://yoursite.com/    # ابدأ بـ10
ab -t 15 -c 50  -k https://yoursite.com/
ab -t 15 -c 200 -k https://yoursite.com/    # ارفع حتى تبدأ الأخطاء
# راقب: Requests per second · 95% (p95) · Failed requests

💡 نصيحة: اختبر صفحةً عامّة (قابلة للكاش) وأخرى ديناميكية (كالسلّة) لتعرف سقفَيك: الأعلى للزوّار، والأدنى للعمليات الديناميكية. وابدأ بتزامن منخفض وارفعه حتى يظهر أول فشل — تلك نقطة انهيارك. للمراجع: ApacheBench وFastCGI Cache.

الخلاصة

«كم زائرًا يتحمّل VPS؟» سؤال إجابته بالقياس لا بالمواصفات. كما أثبتنا بأرقام حقيقية على خادم مرام، خادم بأربع أنوية يتحمّل ~10 طلبات متزامنة بلا كاش — وينهار عند 100 — بينما يقفز إلى أكثر من 1000 متزامن مع كاش الصفحات، بنفس العتاد وصفر فشل. لذا قبل أن تشتري خادمًا أقوى، فعّل الكاش واضبط إعدادك؛ وقبل موسم الذروة، اختبر سقفك بنفسك لتعرف متى ينهار — قبل أن ينهار أمام عملائك. السعة الحقيقية = عتاد جيّد + كاش صحيح + إعداد مضبوط.