VPS संसाधन कैलकुलेटर

पहले पैकेज का नाम नहीं, बोझ का स्वभाव

VPS चुनते समय पैकेज का नाम आसानी से धोखा देता है। “Basic”, “standard”, “premium”, “general purpose”… अच्छे लगते हैं। लेकिन इनमें से कोई भी नाम अकेले यह नहीं बताता कि साइट कितनी RAM खाएगी, CPU कब घुटेगा या डिस्क किस दिन भरेगी।

एक स्टैटिक साइट और WooCommerce स्टोर, भले ही समान विज़िटर लें, उन्हें एक जैसे सर्वर की ज़रूरत नहीं होती। एक में तैयार फाइलें सर्व होती हैं; दूसरे में कार्ट, भुगतान, स्टॉक, उपयोगकर्ता सत्र, डेटाबेस क्वेरी, एडमिन पैनल, और कभी-कभी बैकग्राउंड में चलने वाले कतार कार्य भी होते हैं। फर्क बिल्कुल यहीं है।

यह कैलकुलेशन मॉडल VPS को चार मुख्य संसाधनों पर पढ़ता है: vCPU, RAM, डिस्क और मासिक ट्रैफ़िक। लेकिन इन्हें केवल संख्या की तरह नहीं लेता; अनुप्रयोग प्रकार, पर्यावरण स्तर, cache/CDN उपयोग, उसी VPS में चलने वाली सेवाएँ, लॉग्स, स्थानीय बैकअप और विकास भत्ता के साथ मूल्यांकन करता है।

कोई एक "आधिकारिक VPS फॉर्मूला" नहीं है। वैसे भी बड़े क्लाउड प्रदाताओं के दस्तावेज़ों में इस मुद्दे को ऐसे ही लिया जाता है: CPU, मेमोरी, नेटवर्क और स्टोरेज को साथ में सोचा जाता है; मशीन परिवार भी वर्कलोड के अनुसार अलग होते हैं। सामान्य उद्देश्य वाली मशीनें अलग होती हैं, compute-भारी मशीनें अलग, memory-भारी मशीनें अलग व्यवहार करती हैं। 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, mail और Docker चलाने वाली मिश्रित स्थापना के लिए?

साथ ही साझा CPU और समर्पित/dedicated CPU का फर्क भी नज़रअंदाज़ होता है। छोटे VPS प्लानों में CPU अक्सर साझा होता है। हल्की वेबसाइटों के लिए यह समस्या नहीं हो सकती। लेकिन नियमित worker चलाने वाली, अचानक ट्रैफ़िक पाने वाली, रिपोर्ट बनाने वाली या डेटाबेस पर बार-बार भार डालने वाली प्रणालियों में समान vCPU संख्या अपेक्षा से कमज़ोर महसूस हो सकती है।

इसलिए यहाँ का आउटपुट "पक्का प्लान" नहीं, बल्कि सुरक्षित शुरुआती अनुमान के रूप में पढ़ा जाना चाहिए। संसाधन चयन के लिए अच्छा पहला चित्र देता है। उत्पादन में अंतिम शब्द फिर भी मेट्रिक्स बोलते हैं: CPU उपयोग, RAM खपत, डिस्क भराव, नेटवर्क ट्रैफ़िक, धीमी क्वेरीज़, त्रुटि लॉग्स, worker कतार।

कागज़ अलग, सर्वर अलग।

कहाँ से शुरू करते हैं?

हिसाब का पहला विभाजन अनुप्रयोग प्रकार से आता है। क्योंकि हर अनुप्रयोग वर्ग का आधार भार समान नहीं होता।

स्टैटिक साइट सबसे हल्की तरफ होती है। आधार CPU 1 vCPU, आधार RAM 1 GB माना जाता है; CPU कारक भी 0.2 जैसा कम रखा जाता है। यह समझदारी है। क्योंकि अच्छी तरह cache की गई स्टैटिक साइट में सर्वर अक्सर तैयार फ़ाइलें सर्व करता है, अनुप्रयोग परत बहुत कम काम करती है।

WordPress / ब्लॉग के लिए शुरुआत बढ़ती है: आधार CPU 1.5 vCPU, आधार RAM 2 GB, CPU कारक 1। WordPress का PHP और डेटाबेस आधार होता है। थीम, प्लगइन, छवि प्रसंस्करण, एडमिन कार्य, खोज, टिप्पणियाँ—इन सब के चलते यह स्टैटिक साइट की तरह व्यवहार नहीं करता। फिर भी उचित cache के साथ काफी हल्का किया जा सकता है।

WooCommerce / ई-कॉमर्स एक और वर्ग है। इस मॉडल में आधार CPU 2.5 vCPU, आधार RAM 4 GB, CPU कारक 2 लिया जाता है। मेरी राय में ई-कॉमर्स के लिए यह विभाजन ज़रूरी है। क्योंकि WooCommerce, सादे WordPress के ऊपर कार्ट, भुगतान, ऑर्डर, स्टॉक और सदस्यता परत जोड़ता है। इसके अलावा कुछ पेज पूरी तरह cache के अनुकूल नहीं होते। उत्पाद पेज cache से आ सकता है, लेकिन कार्ट और भुगतान की तरफ काम बदल जाता है।

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 स्थापनाओं में worker और मेमोरी योजना वैसे भी अलग से सोची जाती है। रिपोर्टिंग, उपयोगकर्ता सत्र, मॉड्यूल, डेटाबेस संचालन और लंबे समय तक चलने वाले कार्य इस वर्ग को सामान्य ब्लॉग साइट से अलग करते हैं।

गेम सर्वर के लिए आधार CPU 3 vCPU, आधार RAM 4 GB, CPU कारक 2.5; bot / worker तरफ आधार CPU 2 vCPU, आधार RAM 2 GB, CPU कारक 1.5 माना जाता है। विशेष रूप से worker-प्रकार के कार्यों में विज़िटर संख्या भ्रामक हो सकती है। भले ही कोई साइट में प्रवेश न करे, पृष्ठभूमि में डेटा संसाधित हो रहा होता है।

पर्यावरण चयन आधार मान के ऊपर गुणांक की तरह चढ़ता है। परीक्षण / शौकिया पर्यावरण 0.75, छोटा production 1, production 1.25, उच्च उपलब्धता तैयारी 1.6 गुणांक से सोचा जाता है। उच्च उपलब्धता तैयारी का मतलब "एक VPS अब HA हो गया" नहीं है; केवल अधिक व्यापक संसाधन हिस्सा छोड़ना है। असली HA अलग वास्तुकला चाहता है।

विकास भत्ता भी सबसे अंत में आता है। डिफ़ॉल्ट 30 प्रतिशत। मेरी राय में उचित। 3-6 महीने की वृद्धि अपेक्षा को पूरा करने के लिए अच्छा अंतराल। 300 प्रतिशत लिखा जा सकता है, लेकिन यदि वास्तव में ऐसी वृद्धि अपेक्षित नहीं है तो हिसाब डर का हिसाब बन जाता है।

ट्रैफ़िक हिसाब: मासिक औसत थोड़ा धोखा देता है

मासिक विज़िटर संख्या पहले देखने का आँकड़ा है, लेकिन अंतिम निर्णय के लिए कमज़ोर पड़ता है। 100 हज़ार विज़िटर पाने वाली दो साइटें समान भार उत्पन्न नहीं कर सकतीं। एक प्रति विज़िटर 1.5 पेज दिखाती है, पेज का आकार 1 MB है, CDN अच्छा काम कर रहा है। दूसरी प्रति विज़िटर 4 पेज दिखाती है, पेज का आकार 3 MB है, गतिशील क्षेत्र अधिक हैं। समान विज़िटर, बिल्कुल अलग सर्वर भार।

ट्रैफ़िक हिसाब विज़िटर संख्या, पेज / सत्र मान और औसत पेज आकार को साथ लेता है। ऊपर cache प्रभाव घटाया जाता है, विकास भत्ता जोड़ा जाता है और परिणाम GB में बदल दिया जाता है। अंतिम मान 50 GB के चरणों में पूर्णांकित होता है; बहुत छोटे परिदृश्यों में भी न्यूनतम 50 GB ट्रैफ़िक दिखाया जाता है।

Cache की तरफ उपयोग की जाने वाली मान्यताएँ इस प्रकार हैं: cache नहीं तो बचत 0, बुनियादी cache 35 प्रतिशत, पेज + object cache 60 प्रतिशत, CDN + मज़बूत cache 75 प्रतिशत। ये आधिकारिक गारंटी मान नहीं हैं। NGINX cache या CDN उपयोग करने पर origin सर्वर भार घटने की उम्मीद होती है; लेकिन वास्तविक बचत cache hit दर, पेज संरचना और गतिशील क्षेत्रों पर निर्भर करती है।

विशेष रूप से WooCommerce में इस पर ध्यान दें। CDN होने से कार्ट और भुगतान पेज अचानक मुफ्त नहीं हो जाते। व्यक्तिगत सामग्री, सत्र, एडमिन कार्य, भुगतान प्रवाह, स्टॉक नियंत्रण जैसी जगहों पर cache अधिक सीमित है। Cache एक अच्छा ब्रेक है; मोटर की जगह नहीं लेता।

व्यस्त घंटे का गुणक अलग से है। मासिक ट्रैफ़िक समान रूप से वितरित नहीं होता। अभियान दिवस, न्यूज़लेटर भेजना, सोशल मीडिया साझाकरण, समाचार साइटों में अचानक वृद्धियाँ… औसत मान शांत दिखता है, लेकिन सर्वर एक घंटे के लिए पसीना बहा सकता है। इस हिसाब में Peak RPS लगभग मासिक विज़िटर × पेज / सत्र × व्यस्त घंटा गुणक को 30 दिनों के सेकंडों की संख्या से विभाजित करके निकाला जाता है। 30 दिन, 2,592,000 सेकंड।

CPU पर ट्रैफ़िक का प्रभाव और भी दिलचस्प है। विज़िटर संख्या को 50,000 के सापेक्ष अनुपातित किया जाता है, कार्यभार को CPU कारक से गुणा किया जाता है, व्यस्त घंटा गुणक जोड़ा जाता है, cache प्रभाव का आधा CPU की तरफ से घटाया जाता है। यानी cache ट्रैफ़िक को गंभीरता से घटाता है, लेकिन CPU प्रभाव अधिक सतर्कता से कम किया जाता है। मेरी राय में सही दृष्टिकोण; क्योंकि हर अनुरोध cache से नहीं लौटता।

स्टैटिक cached साइट परीक्षण में 100 हज़ार मासिक विज़िटर, 1.5 पेज / सत्र, 1 MB पेज आकार, व्यस्त घंटा गुणक 2, CDN + मज़बूत cache और 20 प्रतिशत विकास भत्ता के साथ परिणाम 1 vCPU, 2 GB RAM, 40 GB डिस्क, 50 GB मासिक ट्रैफ़िक स्तर पर रहता है। ट्रैफ़िक है लेकिन भार हल्का।

ई-कॉमर्स उदाहरण में वही आराम नहीं है। 200 हज़ार मासिक विज़िटर, 4 पेज / सत्र, 3 MB औसत पेज आकार, व्यस्त घंटा गुणक 5, पेज + object cache और 50 प्रतिशत विकास भत्ता के साथ मासिक ट्रैफ़िक 1450 GB तक पहुँच जाता है। CPU सुझाव 32 vCPU। पहली नज़र में अधिक लग सकता है; लेकिन संख्याओं को एक के ऊपर एक रखने पर तस्वीर कठोर होती है: अधिक विज़िटर, अधिक पेज, बड़ा पेज, भारी कार्यभार, ऊँचा peak।

पेज आकार अलग परेशानी है। "साइट हल्की है" कहना पर्याप्त नहीं, मापना ज़रूरी है। बड़ी छवियाँ, फॉन्ट, तृतीय-पक्ष स्क्रिप्ट, विज्ञापन कोड, एनालिटिक्स टैग, अनावश्यक JS फ़ाइलें ट्रैफ़िक को फुलाती हैं। ब्राउज़र में जल्दी खुलने का मतलब यह नहीं कि डेटा स्थानांतरण छोटा है।

उसी बॉक्स में कौन काम कर रहा है?

छोटे VPS में असली लड़ाई अक्सर यहीं होती है। वेब सर्वर अकेला नहीं रहता। MySQL भी उसी जगह है, Redis भी, पैनल भी, शायद मेल सेवा भी। इसमें Docker कंटेनर और worker प्रक्रियाएँ जोड़ दीं तो 2 GB RAM की साँस फूल जाती है।

यदि डेटाबेस उसी VPS के भीतर है तो मॉडल में RAM अतिरिक्त भार जुड़ता है। डेटाबेस आकार को 20 से विभाजित किया जाता है; परिणाम न्यूनतम 1 GB, अधिकतम 8 GB तक सीमित रखा जाता है। उदाहरण के लिए 5 GB डेटाबेस के लिए भी 1 GB RAM हिस्सा अलग रखा जाता है। 30 GB डेटाबेस के लिए लगभग 1.5 GB अतिरिक्त भार बनता है। CPU की तरफ डेटाबेस के लिए 0.5 vCPU जोड़ा जाता है।

ये मान डेटाबेस ट्यूनिंग का हिसाब नहीं हैं। यदि इंडेक्स खराब हैं, क्वेरीज़ लंबी हैं, टेबल लॉक हैं तो 0.5 vCPU पर्याप्त नहीं। लेकिन पहली योजना के लिए डेटाबेस को "शून्य लागत" मानने से बेहतर है।

Redis / object cache उसी VPS के भीतर है तो RAM में 0.5 GB जोड़ा जाता है। Redis मेमोरी में चलता है; इसे भूलने पर छोटे सर्वर में अजीब सुस्ती दिखती है। Cache प्रदर्शन बढ़ाने के लिए स्थापित किया गया है, हाँ, लेकिन उसे भी RAM चाहिए।

प्रबंधन पैनल में तीन स्तर हैं: नहीं, हल्का पैनल, cPanel / Plesk जैसा पूर्ण पैनल। हल्का पैनल RAM में 0.3 GB, CPU में 0.15 vCPU जोड़ता है। पूर्ण पैनल RAM में 1 GB, CPU में 0.3 vCPU जोड़ता है। cPanel या Plesk जैसी प्रणालियों को 1 GB RAM वाले VPS पर स्थापित करके फिर अनुप्रयोग से प्रदर्शन की उम्मीद करना अच्छा विचार नहीं है। पैनल सुविधा देता है; कीमत संसाधनों से चुकानी पड़ती है।

Worker / queue संख्या सीधे प्रभावशाली है। प्रत्येक worker के लिए 0.5 GB RAM और 0.5 vCPU जोड़ा जाता है। यह थोड़ा अधिक लग सकता है, लेकिन यदि पृष्ठभूमि कार्य गंभीर हैं तो समझदारी है। छवि प्रसंस्करण, रिपोर्ट निर्माण, बाहरी API से डेटा खींचना, मेल कतार खाली करना, भुगतान के बाद के कार्य… यदि worker खाली नहीं बैठा है तो संसाधन लेता है।

ईमेल सेवा उसी VPS में चलती है तो 0.5 GB RAM और 0.3 vCPU जोड़ा जाता है। संसाधन वाला हिस्सा अलग, मेल सेवा परिचालन रूप से भी कठिन है। DNS, SPF, DKIM, DMARC, स्पैम, कतार, डिलीवरेबिलिटी। यह हिसाब केवल संसाधन हिस्सा देखता है; सिरदर्द नहीं गिनता।

Docker / कंटेनर उपयोग के लिए 0.5 GB RAM और 0.2 vCPU जोड़ा जाता है। Docker व्यवस्था लाता है लेकिन मुफ्त नहीं है। यदि Docker की मेमोरी सीमा, swap व्यवहार और CPU हिस्सा सही से सेट नहीं किया गया तो एक कंटेनर पूरी मशीन को दबा सकता है। "कंटेनर बना लिया, आराम में हैं" हमेशा सही वाक्य नहीं है।

CPU हिसाब का सार इस प्रकार है: आधार CPU और ट्रैफ़िक CPU आवश्यकता में से जो बड़ा है लिया जाता है, सेवा CPU भार जोड़े जाते हैं, पर्यावरण गुणांक और विकास भत्ता लगाया जाता है। RAM में आधार 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 समझदारी है। Production पर्यावरण में मिलीमीटर-पर-मिलीमीटर हिसाब करना इंसान को छोटे उतार-चढ़ाव पर दीवार के पास ले जाता है।

डिस्क पर असली भार कभी-कभी अदृश्य चीज़ें होती हैं

कोड फ़ोल्डर छोटा है इसलिए डिस्क आवश्यकता छोटी मानी जाती है। यह बहुत देखी गई गणना की गलती है। अनुप्रयोग 3 GB, मीडिया 10 GB; "20 GB डिस्क पर्याप्त है" कहा जाता है। फिर लॉग्स, डेटाबेस, स्थानीय बैकअप, सिस्टम फ़ाइलें, कंटेनर इमेज, अस्थायी फ़ाइलें आती हैं।

डिस्क हिसाब अनुप्रयोग फ़ाइलों, मीडिया / अपलोड, डेटाबेस आकार, दैनिक लॉग, लॉग संग्रहण दिन और स्थानीय बैकअप प्रति के साथ किया जाता है। यदि डेटाबेस उसी VPS में नहीं है तो डिस्क हिसाब में नहीं आता। यदि उसी VPS में है तो आता है।

पहले डिस्क मध्यवर्ती योग बनता है: अनुप्रयोग फ़ाइलें + मीडिया फ़ाइलें + (उसी VPS में हो तो डेटाबेस) + दैनिक लॉग × संग्रहण दिन। फिर स्थानीय बैकअप प्रति की संख्या को शामिल किया जाता है। एक स्थानीय बैकअप डेटा सेट को मोटे तौर पर एक बार और बढ़ाता है। ऊपर 15 GB सिस्टम हिस्सा जोड़ा जाता है, 20 प्रतिशत सुरक्षा अंतर लगाया जाता है, विकास भत्ता भी जोड़ा जाता है। परिणाम 10 GB के चरणों में पूर्णांकित होता है और न्यूनतम 20 GB सुझाया जाता है।

15 GB सिस्टम हिस्सा छोटा न दिखे। ऑपरेटिंग सिस्टम, पैकेज, अपडेट अवशेष, अस्थायी फ़ाइलें, सेवा लॉग्स, Docker इमेज, डेटाबेस अस्थायी फ़ाइलें वहाँ से स्थान लेती हैं। Production में डिस्क केवल आपका अपलोड फ़ोल्डर नहीं है।

लॉग्स भी छली होते हैं। प्रतिदिन 0.5 GB लॉग और 14 दिन संग्रहण = 7 GB। प्रतिदिन 2 GB लॉग और 30 दिन संग्रहण = 60 GB। चुपचाप बढ़ते हैं। डिस्क 80 प्रतिशत पार करती है, फिर 90, फिर एक deploy के दौरान वह प्रसिद्ध त्रुटि: no space left on device।

स्थानीय बैकअप भी ध्यान माँगता है। उसी डिस्क पर बैकअप रखना आपदा परिदृश्य में पूर्ण सुरक्षा नहीं है; डिस्क गई तो बैकअप भी गया। लेकिन त्वरित वापसी के लिए एक स्थानीय प्रति काम दे सकती है। मॉडल इसे संसाधन हिसाब में शामिल करता है। दूरस्थ बैकअप, ऑब्जेक्ट स्टोरेज, अलग बैकअप सर्वर जैसे निर्णय अलग से योजना बनाने चाहिए।

WordPress production परीक्षण में 5 GB अनुप्रयोग फ़ाइल, 10 GB मीडिया, 5 GB डेटाबेस, दैनिक 0.5 GB लॉग, 14 दिन संग्रहण, 1 स्थानीय बैकअप और 30 प्रतिशत विकास भत्ता के साथ डिस्क 90 GB सुझाई जाती है। पहली नज़र में अधिक। लेकिन लॉग, बैकअप, सिस्टम हिस्सा और सुरक्षा अंतर जोड़ने पर अधिक नहीं, बल्कि सतर्कता है।

ई-कॉमर्स की तरफ काम बढ़ता है: 10 GB अनुप्रयोग फ़ाइल, 80 GB मीडिया, 30 GB डेटाबेस, दैनिक 2 GB लॉग, 30 दिन संग्रहण, 1 स्थानीय बैकअप और 50 प्रतिशत विकास भत्ता। निकलने वाली डिस्क 480 GB। उत्पाद छवियाँ, ऑर्डर डेटा, लॉग और बैकअप उसी बॉक्स में हैं तो यह परिणाम आश्चर्यजनक नहीं।

डिस्क में अधिक बचत करना बुरी आदत है। CPU पर्याप्त नहीं तो सुस्ती दिखती है। RAM पर्याप्त नहीं तो swap शुरू होता है। डिस्क भरने पर सेवाएँ कभी-कभी और कठोर टूटती हैं: डेटाबेस नहीं लिख सकता, लॉग नहीं बनता, सत्र फ़ाइल नहीं खुलती, deploy आधा रह जाता है। इससे बुरा, त्रुटि हमेशा साफ-साफ अपने आप को नहीं बताती।

परिणाम को पैकेज में बदलते समय

आउटपुट में चार मुख्य मान हैं: CPU, RAM, डिस्क और मासिक ट्रैफ़िक। इन्हें एक ही थैले में न डालें। हर एक अलग सीमा दिखाता है।

CPU, तात्कालिक प्रसंस्करण शक्ति है। PHP अनुरोध, Node.js API उत्तर, डेटाबेस क्वेरी, worker कार्य, भुगतान के बाद की प्रक्रिया… ये CPU को छूते हैं। ट्रैफ़िक बढ़ने पर CPU बढ़ सकता है; cache इसे घटा सकता है लेकिन पूरी तरह मिटा नहीं सकता।

RAM, चल रही सेवाओं का स्थान है। MySQL, Redis, PHP-FPM, Node.js प्रक्रियाएँ, पैनल, Docker कंटेनर, मेल सेवा, worker। RAM घटने पर सिस्टम swap में जा सकता है। चलता हुआ दिखता है, लेकिन भारी हो जाता है। विशेष रूप से गतिशील अनुप्रयोगों में यह अंतर जल्दी महसूस होता है।

डिस्क, स्थायी भंडारण है। अनुप्रयोग फ़ाइल, मीडिया, डेटाबेस, लॉग, बैकअप और सिस्टम फ़ाइलें यहाँ देखती हैं। डिस्क हिसाब में आज के आकार से नहीं, कुछ महीनों बाद के संचय से सोचना चाहिए।

मासिक ट्रैफ़िक, डेटा स्थानांतरण है। CDN, cache और पेज अनुकूलन इसे घटाते हैं। प्रदाता की ट्रैफ़िक नीति अलग से जाँचनी चाहिए: कोटा है, अतिरिक्त शुल्क है, गति गिरावट है? हिसाब GB आवश्यकता देता है; प्रदाता की वाणिज्यिक शर्त नहीं देता।

इस मॉडल में कच्चे मान व्यावहारिक पैकेज चरणों में पूर्णांकित होते हैं। यदि 3.4 vCPU की कच्ची आवश्यकता है तो 4 vCPU सुझाया जाता है। यदि 9 GB RAM आवश्यकता है तो 16 GB स्तर तक जा सकते हैं। डिस्क भी 10 GB के चरणों में पूरी की जाती है। यह पूर्णांकन कभी-कभी परिणाम को वास्तविक से बड़ा दिखाता है, लेकिन VPS पैकेज वैसे भी दशमलव में नहीं बिकते।

एक बात और है: 4 vCPU हर प्रदाता पर उसी 4 vCPU की तरह व्यवहार नहीं कर सकता। CPU पीढ़ी, साझा/समर्पित संरचना, वर्चुअलाइजेशन परत, डिस्क प्रकार, नेटवर्क गुणवत्ता, पड़ोसी मशीनें—सभी फर्क पैदा करते हैं। DigitalOcean जैसे प्रदाताओं के प्लान चयन दस्तावेज़ों में साझा और अलग CPU का विभाजन व्यर्थ नहीं दोहराया जाता।

इसलिए यह हिसाब खरीद बटन दबाने से पहले की तकनीकी जाँच की तरह सोचा जाना चाहिए। यदि आपका मौजूदा सिस्टम है तो वास्तविक मेट्रिक्स के साथ सामने रखें: CPU ग्राफ़, RAM उपयोग, डिस्क भराव, नेटवर्क आउटपुट, धीमी क्वेरीज़, 5xx त्रुटियाँ, कतार प्रतीक्षा समय। यदि नई प्रणाली स्थापित कर रहे हैं तो कुछ परिदृश्य आज़माएँ।

Cache न होने पर क्या होता है? CDN चुनने पर ट्रैफ़िक कितना घटता है? डेटाबेस को उसी VPS से अलग करने पर RAM आराम पाती है? Worker संख्या 0 से 4 होने पर CPU कहाँ जाता है? स्थानीय बैकअप प्रति डिस्क को कितना बड़ा करती है?

पैकेज चयन कभी-कभी इन सवालों के उत्तरों से निकलता है, केवल एक परिणाम पंक्ति से नहीं।

अगर मैं होता तो विशेष रूप से तीन मानों पर फिर से देखता: व्यस्त घंटा गुणक, डेटाबेस का उसी VPS में होना, और स्थानीय बैकअप प्रति। क्योंकि असल जीवन में हिसाब को सबसे ज्यादा ये ही बिगाड़ते हैं। ट्रैफ़िक एक घंटे में जमा हो जाता है, MySQL उसी बॉक्स में अपेक्षा से अधिक RAM खाता है, बैकअप डिस्क भर देते हैं। फिर हर कोई CPU पैकेज पर नाराज़ होता है।

कभी-कभी दोष CPU का नहीं होता।