حاسبة موارد VPS

اسم الحزمة ليس المهم، بل طبيعة الحمل

عند اختيار VPS، اسم الحزمة قد يخدعك بسهولة. "Basic"، "standard"، "premium"، "general purpose"... تبدو جميلة. لكن لا يمكن لأي من هذه الأسماء أن يخبرك وحدها بمقدار الذاكرة العشوائية التي سيستهلكها موقعك، أو متى سيختنق المعالج، أو في أي يوم سيمتلئ القرص.

الموقع الثابت ومتجر WooCommerce حتى لو استقبلا نفس الزائر، لا يحتاجان إلى نفس الخادم. في أحدهما تُخدم ملفات جاهزة؛ وفي الآخر توجد سلة التسوق، والدفع، والمخزون، وجلسة المستخدم، واستعلامات قاعدة البيانات، ولوحة الإدارة، وأحيانًا مهام خلفية قيد التشغيل. الفرق هنا بالضبط.

نموذج الحساب هذا يقرأ VPS عبر أربعة موارد رئيسية: vCPU، RAM، القرص، وحركة المرور الشهرية. لكنه لا يأخذها كأرقام مجردة؛ بل يقيّمها مع نوع التطبيق، ومستوى البيئة، واستخدام الكاش/CDN، والخدمات التي تعمل داخل نفس VPS، والسجلات، والنسخ الاحتياطية المحلية، وهامش النمو.

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

flowchart LR
  A["نوع التطبيق"] --> E["تقدير الموارد"]
  B["الحركة والكاش"] --> E
  C["قاعدة البيانات، عامل، لوحة، Docker"] --> E
  D["القرص، السجل، النسخ الاحتياطي، هامش النمو"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["القرص"]
  E --> I["الحركة الشهرية"]

الجملة التي أكرهها أكثر من غيرها في مثل هذه الحسابات هي: "2 vCPU يكفي". يكفي ماذا؟ لموقع ثابت، أم لمتجر WooCommerce، أم لتطبيق Odoo، أم لـ Node API، أم لإعداد مختلط يعمل فيه MySQL وRedis والبريد وDocker على نفس الصندوق؟

كما أن الفرق بين CPU المشترك وCPU المخصص/المحجوز لا يُرى غالبًا. في خطط VPS الصغيرة، تكون المعالجات عادةً مشتركة. قد لا يكون هذا مشكلة للمواقع الخفيفة. لكن في الأنظمة التي تشغّل مهامًا منتظمة، أو تستقبل حركة لحظية، أو تولّد تقارير، أو تثقل على قاعدة البيانات بشكل متكرر، قد يبدو نفس عدد vCPU أضعف من المتوقع.

لذلك، يجب قراءة المخرجات هنا على أنها "تقدير بداية آمن" وليس "خطة محددة". إنها تعطي صورة أولية جيدة لاختيار الموارد. وفي الإنتاج، الكلمة الأخيرة تكون دائمًا للمقاييس: استخدام CPU، استهلاك RAM، امتلاء القرص، حركة الشبكة، الاستعلامات البطيئة، سجلات الأخطاء، وطوابير العمالة.

الورق شيء والخادم شيء آخر.

من أين نبدأ؟

التمييز الأول في الحساب يأتي من نوع التطبيق. لأن الحمل الأساسي لكل فئة تطبيق ليس متساويًا.

الموقع الثابت يقف على الجانب الأخف. يُعتبر CPU الأساسي 1 vCPU وRAM الأساسي 1 GB؛ كما يُضبط عامل CPU عند 0.2. هذا منطقي. لأن الموقع الثابت الذي يتم تخزينه جيدًا (cache) يخدم غالبًا ملفات جاهزة، بينما تعمل طبقة التطبيق قليلًا جدًا.

بالنسبة لـ WordPress / المدونات، يبدأ المبلغ الأساسي في الارتفاع: CPU الأساسي 1.5 vCPU، RAM الأساسي 2 GB، وعامل CPU 1. WordPress له أساس PHP وقاعدة بيانات. القالب والإضافات ومعالجة الصور وعمليات الإدارة والبحث والتعليقات تجعله لا يتصرف مثل موقع ثابت. ومع ذلك، يمكن تخفيفه كثيرًا باستخدام كاش جيد.

WooCommerce / التجارة الإلكترونية فئة أخرى. في هذا النموذج، CPU الأساسي 2.5 vCPU، RAM الأساسي 4 GB، وعامل CPU 2. إذا سألتني، فهذا التمييز ضروري للتجارة الإلكترونية. لأن WooCommerce يضيف فوق WordPress العادي طبقة سلة التسوق والدفع والطلبات والمخزون والعضويات. كما أن بعض الصفحات غير مناسبة للتخزين الكامل. صفحة المنتج يمكن أن تأتي من الكاش، لكن في جانب السلة والدفع تتغير الأمور.

لتطبيقات Laravel / PHP و Node.js / API، يكون CPU الأساسي 2 vCPU، RAM الأساسي 3 GB، وعامل CPU 1.2. هنا، تعتمد الحاجة الفعلية بشكل كبير على الكود. يمكن لـ API بسيط أن يعمل بخفة شديدة؛ بينما التطبيق الذي يخاطب خدمات خارجية، ويعالج البيانات باستمرار، ويستخدم قوائم انتظار، قد يكون أثقل بكثير ضمن نفس الفئة.

بالنسبة لـ SaaS الصغير، CPU الأساسي 3 vCPU، RAM الأساسي 4 GB، وعامل CPU 1.8. جلسات المستخدم، والمهام الخلفية، والإشعارات، والتقارير، وحركة قاعدة البيانات تأتي عادةً معًا. عدد الزوار قد يبدو صغيرًا، لكن العمليات داخل التطبيق كثيرة. إذا نظرت إليه كموقع ويب، ستختار الحزمة الخاطئة.

الأنظمة المشابهة لـ Odoo / ERP تقع على الجانب الثقيل: CPU الأساسي 4 vCPU، RAM الأساسي 8 GB، وعامل CPU 3. في تثبيتات Odoo، يتم التفكير في تخطيط العمالة والذاكرة بشكل إضافي بالفعل. إعداد التقارير، وجلسات المستخدم، والوحدات، وعمليات قاعدة البيانات، والمهام الطويلة تميز هذه الفئة عن موقع المدونة العادي.

بالنسبة لخادم اللعبة، CPU الأساسي 3 vCPU، RAM الأساسي 4 GB، وعامل CPU 2.5؛ وفي جانب البوت / العامل، يُفترض CPU أساسي 2 vCPU، RAM أساسي 2 GB، وعامل CPU 1.5. خاصة في الأعمال من نوع (worker)، قد يكون عدد الزوار مضللًا. حتى لو لم يدخل أحد إلى الموقع، فقد تتم معالجة البيانات في الخلفية.

يُضاف اختيار البيئة كمعامل فوق القيمة الأساسية. بيئة الاختبار / الهواية 0.75، والإنتاج الصغير 1، والإنتاج 1.25، والاستعداد للتوافر العالي 1.6. الاستعداد للتوافر العالي لا يعني "أن VPS واحد أصبح HA الآن"؛ إنه فقط ترك حصة موارد أوسع. التوافر العالي الحقيقي يتطلب معمارية منفصلة.

هامش النمو يظهر في النهاية. الافتراضي هو 30 بالمائة. أعتقد أنه معقول. نطاق جيد لاستيعاب توقع النمو خلال 3-6 أشهر. يمكن كتابة 300 بالمائة، لكن إذا لم يكن هناك نمو كهذا بالفعل، يتحول الحساب إلى حساب تخويف.

حساب الحركة: متوسط الشهر يخدع قليلًا

عدد الزوار الشهري هو أول ما يُنظر إليه، لكنه يظل ضعيفًا للقرار النهائي. قد لا يولّد موقعان يستقبلان 100 ألف زائر نفس الحمولة. أحدهما يعرض 1.5 صفحة لكل زائر، بحجم صفحة 1 ميجابايت، ويعمل CDN بشكل جيد. الآخر يعرض 4 صفحات لكل زائر، بحجم صفحة 3 ميجابايت، ولديه مناطق ديناميكية أكثر. نفس الزائر، حمولة خادم مختلفة تمامًا.

حساب الحركة يأخذ عدد الزوار، وقيمة الصفحات / الجلسة، ومتوسط حجم الصفحة معًا. ثم يُخصم تأثير الكاش، ويُضاف هامش النمو، وتُحول النتيجة إلى جيجابايت. تُقرب القيمة النهائية إلى درجات 50 جيجابايت؛ وفي السيناريوهات الصغيرة جدًا، يُعرض حد أدنى 50 جيجابايت من الحركة.

الافتراضات المستخدمة في جانب الكاش هي كالتالي: إذا لم يكن هناك كاش، التوفير 0، الكاش الأساسي 35 بالمائة، كاش الصفحة + الكاش الكائني 60 بالمائة، CDN + كاش قوي 75 بالمائة. هذه ليست قيمًا مضمونة رسميًا. عند استخدام كاش NGINX أو CDN، يُتوقع انخفاض حمل الخادم الأصلي؛ لكن التوفير الفعلي يعتمد على نسبة إصابة الكاش وبنية الصفحة والمناطق الديناميكية.

انتبه لهذا بشكل خاص في WooCommerce. وجود CDN لا يعني أن صفحتي السلة والدفع أصبحتا مجانيتين فجأة. المحتوى المخصص لكل شخص، والجلسات، وعمليات الإدارة، وتدفق الدفع، وفحص المخزون، تكون فيها حدود الكاش أقل. الكاش فرامل جيدة؛ لا يحل محل المحرك.

هناك أيضًا معامل ساعة الذروة. حركة المرور الشهرية لا تتوزع بالتساوي. يوم الحملة، إرسال النشرة البريدية، مشاركة على وسائل التواصل الاجتماعي، ارتفاعات مفاجئة في المواقع الإخبارية... قد يبدو المتوسط هادئًا بينما يتصبب الخادم عرقًا لمدة ساعة. في هذا الحساب، يُحسب Peak RPS تقريبًا بقسمة (الزوار الشهريون × الصفحات / الجلسة × معامل ساعة الذروة) على عدد الثواني في 30 يومًا. 30 يومًا = 2,592,000 ثانية.

تأثير الحركة على CPU أكثر إثارة للاهتمام. يُنسب عدد الزوار إلى 50,000، ويُضرب عامل العمل في عامل CPU، ويُضاف معامل ساعة الذروة، ثم يُخصم نصف تأثير الكاش من ناحية CPU. أي أن الكاش يقلل الحركة بشكل كبير، لكن تأثير CPU يُخفَّض بحذر أكبر. أعتقد أن هذا هو النهج الصحيح؛ لأن ليس كل طلب يعود من الكاش.

في اختبار موقع ثابت مع كاش: 100 ألف زائر شهري، 1.5 صفحة / جلسة، حجم صفحة 1 ميجابايت، معامل ساعة الذروة 2، CDN + كاش قوي، وهامش نمو 20 بالمائة، تبقى النتيجة عند مستوى 1 vCPU، 2 GB RAM، 40 GB قرص، 50 GB حركة شهرية. الحركة موجودة لكن الوزن خفيف.

في مثال التجارة الإلكترونية، لا يوجد نفس الهدوء. مع 200 ألف زائر شهري، 4 صفحات / جلسة، متوسط حجم صفحة 3 ميجابايت، معامل ساعة الذروة 5، كاش الصفحة + الكاش الكائني، وهامش نمو 50 بالمائة، تصل الحركة الشهرية إلى 1450 جيجابايت. توصية CPU هي 32 vCPU. قد تبدو عالية من النظرة الأولى؛ لكن عند وضع الأرقام فوق بعضها، تتصلب الصورة: مزيد من الزوار، مزيد من الصفحات، حجم صفحة أكبر، عبء عمل أثقل، ذروة أعلى.

حجم الصفحة مشكلة منفصلة. قول "الموقع خفيف" لا يكفي، بل يجب قياسه. الصور الكبيرة، والخطوط، والسكريبتات من جهات خارجية، ورموز الإعلانات، وعلامات التحليلات، وملفات JS غير الضرورية تضخم الحركة. أن الموقع يُفتح بسرعة في المتصفح لا يعني أن كمية البيانات المنقولة صغيرة.

من يعمل في نفس الصندوق؟

في VPS الصغيرة، ينشأ الشجار الحقيقي هنا غالبًا. خادم الويب لا يقف وحده. MySQL في نفس المكان، وRedis أيضًا، ولوحة التحكم، وربما خدمة البريد. وعند إضافة حاويات Docker وعمليات العمالة، ينقطع نفس 2 غيغابايت RAM.

إذا كانت قاعدة البيانات داخل نفس VPS، يضيف النموذج عبئًا إضافيًا على الذاكرة. يُقسَم حجم قاعدة البيانات على 20؛ وتُحصر النتيجة بين حد أدنى 1 GB وحد أقصى 8 GB. على سبيل المثال، حتى بالنسبة لقاعدة بيانات بحجم 5 جيجابايت، يُخصص 1 جيجابايت من RAM. بالنسبة لقاعدة بيانات بحجم 30 جيجابايت، يُضاف حوالي 1.5 جيجابايت. في جانب CPU، يُضاف 0.5 vCPU لقاعدة البيانات.

هذه القيم ليست حساب ضبط قاعدة البيانات. إذا كانت الفهارس سيئة، أو الاستعلامات طويلة، أو هناك أقفال على الجداول، فلن يكفي 0.5 vCPU. لكنها أفضل من اعتبار قاعدة البيانات "بتكلفة صفرية" في التخطيط الأولي.

إذا كان Redis / كاش الكائنات داخل نفس VPS، يُضاف 0.5 GB إلى الذاكرة. يعمل Redis في الذاكرة؛ نسيان هذا يؤدي إلى تباطؤ غريب على الخوادم الصغيرة. لقد أُنشئ لتحسين أداء الكاش، نعم، لكنه هو نفسه يحتاج إلى RAM.

لوحة الإدارة لها ثلاثة مستويات: لا شيء، لوحة خفيفة، لوحة كاملة مثل cPanel / Plesk. اللوحة الخفيفة تضيف 0.3 GB إلى RAM و0.15 vCPU إلى CPU. اللوحة الكاملة تضيف 1 GB إلى RAM و0.3 vCPU إلى CPU. تثبيت أنظمة مثل cPanel أو Plesk على VPS بذاكرة 1 GB ثم توقع أداء جيد من تطبيق ليس فكرة جيدة. توفر اللوحة راحة، وتدفع ثمنها بالموارد.

عدد العمال / قوائم الانتظار له تأثير مباشر. يُضاف لكل عامل 0.5 GB RAM و0.5 vCPU. قد يبدو هذا مرتفعًا بعض الشيء، لكنه منطقي إذا كانت المهام الخلفية جادة. معالجة الصور، وتوليد التقارير، وجلب البيانات من واجهات برمجية خارجية، وتفريغ قائمة البريد، والمهام بعد الدفع... العامل لا يظل خاملًا، فهو يستهلك موارد.

إذا كانت خدمة البريد الإلكتروني تعمل داخل نفس VPS، يُضاف 0.5 GB RAM و0.3 vCPU. بغض النظر عن الموارد، فإن خدمة البريد الإلكتروني مزعجة تشغيليًا أيضًا. DNS، SPF، DKIM، DMARC، البريد العشوائي، قائمة الانتظار، قابلية التسليم. هذا الحساب يرى حصة الموارد فقط؛ لا يحسب الصداع.

بسبب استخدام Docker / الحاويات، يُضاف 0.5 GB RAM و0.2 vCPU. يجلب Docker النظام لكنه ليس مجانيًا. إذا لم يتم ضبط حدود الذاكرة، وسلوك Swap، وحصة CPU بشكل صحيح، يمكن لحاوية واحدة أن تزحم الجهاز بأكمله. "لقد حاوينا، وارتحنا" ليست جملة صحيحة دائمًا.

جوهر حساب CPU هو: يُؤخذ الأكبر من CPU الأساسي واحتياج CPU من الحركة، ثم تُضاف أعباء خدمات CPU، ثم يُطبق معامل البيئة وهامش النمو. في الذاكرة، يُجمع RAM الأساسي مع RAM الخدمات، ويُضاف مرة أخرى البيئة وهامش النمو. ثم تُقرب النتيجة إلى درجات حزم عملية: في CPU: 1، 2، 4، 6، 8، 12، 16، 24، 32، 64؛ وفي RAM: 1، 2، 4، 8، 16، 32، 64، 128 GB.

لا يوجد عالم كسور. إذا ظهرت حاجة إلى 5.3 GB RAM، ننظر إلى 8 GB. إذا ظهر 3.1 vCPU، يكون 4 vCPU منطقيًا. في بيئة الإنتاج، الحساب المليمتري يقربك إلى الحائط عند أصغر تذبذب.

القرص: العبء الحقيقي أحيانًا في أشياء غير مرئية

يُظن أن حاجة القرص صغيرة لمجرد أن مجلد الكود صغير. هذا خطأ شائع نراه كثيرًا. التطبيق 3 جيجابايت، الوسائط 10 جيجابايت؛ فيُقال "20 جيجابايت قرص يكفي". ثم تأتي السجلات، وقاعدة البيانات، والنسخة الاحتياطية المحلية، وملفات النظام، وصور الحاويات، والملفات المؤقتة.

يتم حساب القرص من ملفات التطبيق، والوسائط / الرفع، وحجم قاعدة البيانات، وسجل اليومي، وأيام الاحتفاظ بالسجلات، ونسخة احتياطية محلية. إذا لم تكن قاعدة البيانات داخل نفس VPS، فإنها لا تدخل في حساب القرص. أما إذا كانت داخله، فتدخل.

أولًا يُشكل المجموع الفرعي للقرص: ملفات التطبيق + ملفات الوسائط + قاعدة البيانات (إذا كانت في نفس VPS) + السجل اليومي × أيام الاحتفاظ. ثم يُؤخذ عدد النسخ الاحتياطية المحلية في الحسبان. نسخة احتياطية محلية واحدة تضاعف حجم مجموعة البيانات تقريبًا مرة واحدة. ثم يُضاف 15 جيجابايت كحصة للنظام، ويُطبق فراغ أمان بنسبة 20 بالمائة، ويُضاف هامش النمو. تُقرب النتيجة إلى درجات 10 جيجابايت، مع توصية بحد أدنى 20 جيجابايت.

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

السجلات ماكرة أيضًا. 0.5 جيجابايت يوميًا من السجلات و14 يومًا من الاحتفاظ تعطي 7 جيجابايت. 2 جيجابايت يوميًا و30 يومًا احتفاظ تعطي 60 جيجابايت. تنمو بصمت. يصل القرص إلى 80 بالمائة، ثم 90، ثم أثناء عملية نشر يحدث الخطأ الشهير: no space left on device.

النسخة الاحتياطية المحلية تتطلب انتباهًا إضافيًا. الاحتفاظ بنسخة احتياطية على نفس القرص ليس ضمانًا كاملًا في سيناريو الكارثة؛ إذا اختفى القرص، تختفي النسخة الاحتياطية أيضًا. لكن للاستعادة السريعة، قد تفيد نسخة محلية. يدمج النموذج هذا في حساب الموارد. قرارات مثل النسخ الاحتياطي عن بُعد، وتخزين الكائنات، وخادم نسخ احتياطي منفصل يجب التخطيط لها بشكل منفصل.

في اختبار إنتاج WordPress: 5 جيجابايت ملفات تطبيق، و10 جيجابايت وسائط، و5 جيجابايت قاعدة بيانات، وسجل يومي 0.5 جيجابايت، و14 يومًا احتفاظ، ونسخة احتياطية محلية واحدة، وهامش نمو 30 بالمائة، يُوصى بقرص 90 جيجابايت. يبدو كثيرًا من النظرة الأولى. لكن عند إضافة السجلات، والنسخة الاحتياطية، وحصة النظام، وفراغ الأمان، يصبح كثيرًا، بل هو أكثر حذرًا.

في جانب التجارة الإلكترونية، يكبر الأمر: 10 جيجابايت ملفات تطبيق، و80 جيجابايت وسائط، و30 جيجابايت قاعدة بيانات، وسجل يومي 2 جيجابايت، و30 يومًا احتفاظ، ونسخة احتياطية محلية واحدة، وهامش نمو 50 بالمائة. الناتج هو 480 جيجابايت قرص. إذا كانت صور المنتجات وبيانات الطلبات والسجلات والنسخ الاحتياطية في نفس الصندوق، فهذه النتيجة ليست مفاجئة.

البخل في القرص عادة سيئة. إذا لم يكفِ CPU، ترى تباطؤًا. إذا لم تكفِ RAM، يبدأ الـ Swap. إذا امتلأ القرص، قد تتعطل الخدمات بشكل أشد بكثير: قاعدة البيانات لا تستطيع الكتابة، ولا تُنشأ السجلات، ولا يمكن فتح ملف الجلسة، ويعلق النشر. والأسوأ أن الخطأ لا يشرح نفسه دائمًا بوضوح.

تحويل النتيجة إلى حزمة

في المخرجات أربع قيم رئيسية: CPU، RAM، القرص، والحركة الشهرية. لا تضعها في كيس واحد. كل واحد منها يمثل حدًا مختلفًا.

CPU هي قوة المعالجة اللحظية. طلب PHP، واستجابة Node.js API، واستعلام قاعدة بيانات، ومهمة عامل، وعملية بعد الدفع... كل هذه تلمس CPU. عندما تزداد الحركة، قد يزداد CPU؛ يمكن للكاش تقليل ذلك لكنه لا يمحوه تمامًا.

RAM هي مساحة الخدمات قيد التشغيل. MySQL، وRedis، وPHP-FPM، وعمليات Node.js، ولوحة التحكم، وحاويات Docker، وخدمة البريد، والعمال. عندما تقل الذاكرة العشوائية، قد ينزل النظام إلى Swap. يستمر في العمل بشكل مصطنع، لكنه يثقل. في التطبيقات الديناميكية، يُشعر بهذا الفرق بسرعة.

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

الحركة الشهرية هي نقل البيانات. يقللها CDN والكاش وتحسين الصفحات. يجب أيضًا التحقق من سياسة الحركة لدى المزود: هل هناك حصة، أم رسوم تجاوز، أم خفض سرعة؟ الحساب يعطي احتياج الجيجابايت؛ ولا يعطي الشروط التجارية للمزود.

في هذا النموذج، تُقرب القيم الخام إلى درجات حزم عملية. إذا كانت الحاجة الخام 3.4 vCPU، يُوصى بـ 4 vCPU. إذا كانت حاجة الذاكرة 9 جيجابايت، فقد يرتفع المستوى إلى 16 جيجابايت. ويُكمل القرص إلى درجات 10 جيجابايت. هذا التقريب قد يجعل النتيجة تبدو أكبر مما هي عليه أحيانًا، لكن حزم VPS لا تُباع بكسور على أي حال.

وهناك أيضًا هذا: قد لا يتصرف 4 vCPU بنفس الطريقة لدى كل مزود. جيل المعالج، والبنية المشتركة / المخصصة، وطبقة المحاكاة الافتراضية، ونوع القرص، وجودة الشبكة، والأجهزة المجاورة، كلها تصنع فرقًا. المزودون مثل DigitalOcean لا يسلطون الضوء عبثًا على الفرق بين CPU المشترك والمخصص في وثائق اختيار الخطط.

لذلك، يجب التفكير في هذا الحساب على أنه فحص تقني قبل الضغط على زر الشراء. إذا كان لديك نظام حالي، ضعه جنبًا إلى جنب مع المقاييس الحقيقية: مخطط CPU، استخدام الذاكرة، امتلاء القرص، خروج الشبكة، الاستعلامات البطيئة، أخطاء 5xx، ووقت انتظار الطوابير. إذا كنت تنشئ نظامًا جديدًا، جرّب عدة سيناريوهات.

ماذا يحدث عندما لا يوجد كاش؟ بماذا تنخفض الحركة عند اختيار CDN؟ هل ترتاح الذاكرة عند فصل قاعدة البيانات عن نفس VPS؟ أين يذهب CPU عندما يزيد عدد العمال من 0 إلى 4؟ كم تكبر النسخة الاحتياطية المحلية القرص؟

اختيار الحزمة أحيانًا ينبثق من إجابات هذه الأسئلة، وليس من سطر نتيجة واحد.

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

أحيانًا لا يكون الذنب على CPU.