كيف تختار خادم VPS المناسب لمشروعك

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

01ابدأ من الحمل لا من الخطة

قبل أن تفتح صفحة الأسعار، اجمع أربعة أرقام من موقعك الحالي، أو من بيئة اختبار إن كان المشروع جديداً:

• ذروة الطلبات الديناميكية: عدد الطلبات التي ينفذها PHP أو تطبيقك في الثانية في أكثر دقيقة ازدحاماً، دون الصور والملفات الثابتة التي يخدمها خادم الويب أو التخزين المؤقت مباشرة.
• زمن الطلب ووقت المعالج: متوسط زمن تنفيذ الطلب الديناميكي، والجزء الذي يقضيه منه على المعالج فعلاً. الباقي انتظار لقاعدة البيانات أو لخدمة خارجية.
• ذاكرة العامل الواحد: كم يستهلك كل عامل من عمّال PHP-FPM من الذاكرة. في WordPress يتراوح عادةً بين 50 و120 ميغابايت بحسب الإضافات.
• حجم البيانات ونموها: حجم قاعدة البيانات وملفات الموقع اليوم، ووتيرة نموهما الشهري، ومتوسط ما تنقله الصفحة الواحدة إلى الزائر.

إن كنت على استضافة cPanel فسجلات الوصول الخام متاحة لك، وصيغتها الشائعة (combined) واحدة في Apache وNginx، فتعمل عليها الأوامر نفسها:

# أكثر عشر دقائق ازدحاماً بالطلبات الديناميكية، بعد استبعاد الملفات الثابتةgrep -vE '\.(css|js|png|jpe?g|webp|gif|svg|ico|woff2?)' access.log | awk '{print substr($4,2,17)}' | sort | uniq -c | sort -rn | head# متوسط ذاكرة عامل PHP-FPM وعدد العمّال على خادم قائم (عدّل رقم الإصدار)ps -o rss= -C php-fpm8.3 | awk '{s+=$1; n++} END {printf "%.0f MB x %d\n", s/n/1024, n}'# حجم بيانات InnoDB وفهارسها بالميغابايتsudo mysql -e "SELECT ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables WHERE engine='InnoDB';"

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

02المعالج والذاكرة على الورق

لنأخذ «ورد الطائف»، متجراً للورود على ward-taif.com، يعمل بـ WooCommerce. سجلاته تقول إن أكثر دقيقة ازدحاماً في الشهر الماضي حملت 360 طلباً ديناميكياً، أي 6 طلبات في الثانية، بمتوسط 250 ميلي ثانية للطلب، منها نحو 150 ميلي ثانية على المعالج.

المعالج

الأنوية المشغولة في المتوسط = الطلبات في الثانية × وقت المعالج للطلب. هنا 6 × 0.15 = 0.9 نواة لـ PHP، ونضيف نحو نصف نواة لقاعدة البيانات وخادم الويب، فيصبح المجموع 1.4 نواة. ولأنك لا تريد أن يتجاوز الاستهلاك 65% في الذروة، تقسم على 0.65 فتحصل على 2.2، أي 3 أنوية افتراضية (vCPU).

عدد العمّال

العمّال المشغولون في اللحظة نفسها = الطلبات في الثانية × زمن الطلب كاملاً، وهو قانون ليتل المعروف في نظرية الطوابير: 6 × 0.25 = 1.5 عامل في المتوسط. الطلبات الحقيقية تصل على دفعات، فاضرب في 4 أو 5 واضبط pm.max_children على 8. ولا ترفعه أكثر مما تتسع له الذاكرة، فكل عامل ينشط يحجز ذاكرته.

الذاكرة

اجمع الذاكرة مكوناً مكوناً. أكبر بند بعد PHP هو مخزن InnoDB المؤقت: إن كانت قاعدة البيانات وحدها على الخادم فأعطه 50 إلى 70% من الذاكرة، وإن شاركت الخادم مع الموقع فاجعله بحجم البيانات النشطة مع هامش، لا أكثر. واترك ربع الذاكرة فارغاً، لأن النظام يستخدمه مخبئاً للقرص يسرّع القراءة كثيراً.

03القرص وتبادل البيانات

احسب القرص من أربعة بنود: النظام والحزم (5 إلى 8 غيغابايت)، وملفات الموقع، وقاعدة البيانات، والسجلات. ثم أضف مساحة بحجم قاعدة البيانات على الأقل، لأن تفريغها للنسخ الاحتياطي يُكتب على القرص قبل أن يُنقل. في متجر الورود: 6 + 8 + 0.7 + 2 + 1 = نحو 18 غيغابايت. ولا تخطط لإشغال يتجاوز 70%، فقاعدة البيانات تحتاج مساحة لجداولها المؤقتة وسجلاتها، والقرص الممتلئ يوقف الكتابة كلها. نحتاج إذاً نحو 26 غيغابايت اليوم، و40 غيغابايت مع نمو سنة.

أما سرعة القرص فتهم قاعدة البيانات أكثر من سعته. تخزين NVMe يخدم القراءة العشوائية بزمن انتظار أقل من ميلي ثانية عادةً، وهذا ما تحتاجه الاستعلامات التي لا تجد بياناتها في الذاكرة. ونشرح كيف تقيس ذلك بنفسك في مقال مستقل عن الفرق بين VPS وVDS.

وتبادل البيانات الشهري = الصفحات المعروضة × ما تنقله الصفحة فعلاً بعد التخزين المؤقت في المتصفح. المتجر يعرض 600,000 صفحة شهرياً بمتوسط 1.2 ميغابايت، أي نحو 720 غيغابايت، تضاف إليها التحديثات ونقل النسخ الاحتياطية إلى خارج الخادم. وإن خدمت الصور عبر شبكة توصيل محتوى (CDN) انخفض الرقم كثيراً. واسأل المزود: هل يُحسب الاتجاهان، أم الصادر فقط؟

04مركز البيانات: قِس زمن الوصول

كل اتصال HTTPS جديد يحتاج نحو ثلاث رحلات قبل أن يصل أول بايت من الصفحة: واحدة لمصافحة TCP، وواحدة لمصافحة TLS 1.3، وواحدة للطلب نفسه. فإن كان زمن الذهاب والإياب (RTT) بين زائرك والخادم 80 ميلي ثانية، فلن ينزل زمن أول بايت عن 240 ميلي ثانية مهما كان خادمك سريعاً. لذلك يؤثر موقع مركز البيانات في سرعة موقعك أكثر مما تؤثر نواة إضافية.

ولا تفترض أن الأقرب على الخريطة هو الأقرب على الشبكة: مسار الحزم يتبع اتفاقيات الربط بين مزودي الإنترنت، وقد تمر حركة بلد مجاور عبر أوروبا قبل أن تعود. قِس من شبكة جمهورك نفسها، من خط منزلي ومن شبكة جوال لدى stc أو موبايلي أو زين، في ساعة ذروة:

# 50 حزمة إلى عنوان اختبار في كل مركز مرشح: انظر إلى المتوسط والتذبذب (mdev)ping -c 50 203.0.113.10# المسار قفزةً قفزة، مع نسبة الفقد وزمن كل قفزة ورقم الشبكة المستقلة (AS)mtr -rwzc 100 203.0.113.10

من أين تأتي بعنوان اختبار؟ اطلب من المزود عنواناً لكل مركز، أو شغّل خادماً صغيراً يوماً واحداً في كل موقع مرشح. خوادم CoreVPS تُحسب باليوم وبلا عقود، فلا يكلّفك هذا الاختبار إلا أياماً معدودة. ومراكزها اليوم خمسة: ألمانيا وفنلندا والإمارات والولايات المتحدة وسنغافورة. وهكذا تقرأ النتيجة:

• أقل من 40 ميلي ثانية: ممتاز لأي موقع تفاعلي أو لوحة تحكم يعمل عليها فريقك.
• من 40 إلى 100 ميلي ثانية: جيد لمعظم المواقع، والتخزين المؤقت وHTTP/2 وHTTP/3 تخفف أثره.
• أكثر من 100 ميلي ثانية، أو فقد فوق 1%: جرّب مركزاً آخر، أو ضع شبكة توصيل محتوى أمام موقعك، خاصة إن كان التذبذب كبيراً.

05النظام والمحاكاة والنسخ الاحتياطي

بعد الأرقام، خمسة أسئلة تحسم ما تبقى من الاختيار:

• نظام التشغيل: اختر إصداراً طويل الدعم يعرفه فريقك: Ubuntu 24.04 أو 26.04 LTS، أو Debian 13، أو AlmaLinux وRocky Linux إن كانت أدواتك مبنية لعائلة RHEL. وإن كنت ستثبّت لوحة تحكم، فراجع الأنظمة التي تدعمها قبل الطلب. وتذكّر أن Windows Server يضيف تكلفة ترخيص.
• نوع المحاكاة: تأكد أنها محاكاة كاملة مثل KVM، لا حاويات تتشارك نواة المضيف، وإلا فقد لا تستطيع تشغيل Docker أو تحميل وحدات النواة.
• النسخ الاحتياطي: اعرف أين تُحفظ النسخ وكم تتسع. المساحة يجب أن تكفي عدة نسخ لا نسخة واحدة، أي ضعفي حجم بياناتك المضغوطة على الأقل.
• IPv6: كثير من شبكات الجوال حول العالم تعمل اليوم بـ IPv6. اطلب عنواناً، وأضف له سجل AAAA، وتأكد أن خادم الويب وجدار الحماية يعملان عليه.
• الدعم واتفاقية الخدمة: اسأل الدعم الفني سؤالاً تقنياً حقيقياً في أيام التجربة، وقِس سرعة الرد وجودته. واقرأ ما تعوّضه اتفاقية التشغيل: نسبة 99.97% تعني أقل من 13 دقيقة توقف في الشهر.

06من الأرقام إلى الخطة

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

متجر الورود يحتاج 3 vCPU و4 غيغابايت ذاكرة ونحو 40 غيغابايت قرصاً وأقل من 1,000 غيغابايت تبادل بيانات شهرياً، أي VPS Pro تماماً. وكل الخطط تعمل بمحاكاة افتراضية كاملة على معالجات AMD EPYC 9454P وذاكرة DDR5 ECC وتخزين NVMe بمصفوفة RAID 10، مع عنوان IPv4 وعنوان IPv6. وإن احتجت مزيجاً لا تطابقه خطة جاهزة، فصمّم خادمك مورداً مورداً، ورقِّ أي مورد لاحقاً من لوحة التحكم دون إعادة تثبيت.

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

المشكلةقاعدة البيانات تتوقف فجأة، وفي سجل النواة (dmesg) رسالة Out of memory

الحلخفّض pm.max_children أو حجم مخزن InnoDB، وأضف swap شبكةَ أمان. وإن تكرر ذلك مع حمل طبيعي فرقِّ الذاكرة.

المشكلةالمعالج عند 100% كل ليلة في الساعة نفسها

الحلالسبب غالباً مهمة مجدولة: نسخ احتياطي أو ضغط صور أو فهرسة. انقلها إلى وقت أهدأ أو خفّض أولويتها بـ nice قبل أن تشتري أنوية.

المشكلةالذاكرة المستخدمة 90% دائماً لكن الموقع سريع

الحلهذا غالباً مخبئ القرص، وهو سلوك سليم. انظر إلى عمود available في ناتج الأداة free، لا إلى used.

07قبل أن تطلب: قائمة التحقق

1. 01استخرجت ذروة الطلبات الديناميكية في الثانية من السجلات، لا من عدد الزوار الشهري.
2. 02حسبت الأنوية بهدف استهلاك لا يتجاوز 65% في الذروة.
3. 03جمعت الذاكرة مكوناً مكوناً، وتركت ربعها لمخبئ القرص.
4. 04قدّرت القرص لسنة، مع مساحة لتفريغ قاعدة البيانات وإشغال لا يتجاوز 70%.
5. 05قست RTT وmtr من شبكة جمهورك إلى كل مركز مرشح، في ساعة ذروة.
6. 06اخترت نظاماً طويل الدعم تعرفه، ومحاكاة كاملة.
7. 07عرفت أين تُحفظ النسخ الاحتياطية وكم نسخة تتسع.
8. 08جربت الدعم الفني بسؤال تقني حقيقي.

وإن تعارضت الحسابات مع الميزانية، فالأولوية للذاكرة: نقص المعالج يبطئ الموقع، أما نقص الذاكرة فيوقفه.