Linux VPS पर अपने ऐप का लोड मापें
Linux VPS चुनते समय पहले देखें कि आपका ऐप किस operating system, architecture और runtime पर चलता है। फिर एक जैसे काम से CPU, RAM, डिस्क और नेटवर्क मापें। यह लिनक्स VPS की तुलना करने की प्रक्रिया है; किसी provider की ranking या तैयार benchmark नहीं।
VPSuntu · अपडेट · लगभग 6 मिनट में पढ़ें
इस गाइड में
पहले अपना workload लिखें
वेब सर्वर, ऐप runtime, database, cache और background workers की सूची बनाएँ। Import, image processing और backup को भी शामिल करें। केवल वेबसाइट खोलने पर सब ठीक लग सकता है, जबकि इन कामों के साथ चलने पर संसाधन कम पड़ते हैं।
एक छोटे catalogue के लिए Nginx, एक app service, PostgreSQL और scheduled import मानें। 2 vCPU तथा 4 GB RAM परीक्षण की शुरुआत हो सकते हैं; इससे कोई तय visitor capacity साबित नहीं होती। Staging में प्रतिनिधि डेटा रखें, अनावश्यक customer data नहीं। दूसरे शुरुआती बजट मुख्य पेज पर हैं।
Ubuntu, उसके runtime और native extensions का समर्थन जाँचें। amd64 binary को arm64 पर अपने आप चलने योग्य न मानें। मिले हुए image की जाँच अलग चरण है।
तुलना की शर्तें समान रखें
हर candidate पर वही app build, database copy, cache और worker count इस्तेमाल करें। Region और software version बदलने से hardware की तुलना भ्रामक हो सकती है। India में अपने उपयोगकर्ताओं और database के स्थान से network latency मापें; संपर्क का पता data centre का पता नहीं है।
छोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| क्या दर्ज करें | क्यों ज़रूरी है |
|---|---|
| CPU allocation और fair-use नियम | Shared, dedicated और burstable CPU की सीमाएँ अलग हैं |
| RAM और swap | सभी services एक memory budget बाँटती हैं |
| डिस्क और I/O सीमा | खाली जगह तथा response time अलग बातें हैं |
| Region और dependencies | दूर का database request को धीमा कर सकता है |
| Resize और restore | बदलाव में downtime लग सकता है |
| Billing और अतिरिक्त सेवाएँ | एक जैसा VM मूल्य अलग कुल बिल दे सकता है |
VPS सर्वर का vCPU count लगातार मिलने वाली CPU क्षमता नहीं बताता। NVMe नाम से I/O quota भी तय नहीं होता। Provider से पूछें कि आपका sustained workload अनुमत है या नहीं और बढ़ाई हुई disk बाद में छोटी की जा सकती है या नहीं।
लोड के दौरान सर्वर का आधार मापें
Ubuntu पर iostat के लिए sysstat install करें। ऐप का workload चलते समय sampling commands अलग terminals में चलाएँ। खाली server का छोटा sample केवल शुरुआती स्थिति बताता है।
free -h
df -h /
sudo apt update
sudo apt install sysstat
vmstat 1 11
iostat -xz -y 1 10vmstat की पहली CPU/activity पंक्ति boot से अब तक का सार देती है; अगले एक-सेकंड samples देखें। free में available उपयोगी है: cache का कुछ हिस्सा वापस लिया जा सकता है। केवल कम free memory से कमी साबित नहीं होती। iostat का -y पहला दीर्घकालिक sample छोड़ता है।
इस साइट के origin के 24 सितंबर 2026 के एक अवलोकन में एक logical CPU, 957 MiB RAM, 59 MiB free और 358 MiB available थे। इसमें control panel और अन्य services भी थीं। यह अंतर समझाने वाला snapshot था, load test या क्षमता का वादा नहीं। अपने outputs के साथ समय और test scenario लिखें; अलग database volume हो तो उसे भी जाँचें।
वही काम जाँचें जो उपयोगकर्ता करते हैं
अपने नियंत्रण वाले staging में browsing, search, login और एक write operation जाँचें। Cached तथा uncached requests और background jobs रखें। तुलना से पहले स्वीकार्य response time तथा error rate तय करें।
उपयोगकर्ताओं के पास स्थित client से status, first-byte time और कुल समय माप सकते हैं। नीचे अपने staging hostname और path लगाएँ; समय seconds में है।
curl -sS -o /dev/null --max-time 30 -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.com/catalogueएक curl request concurrency नहीं मापती। Load test में अलग client, निश्चित dataset, request rate, concurrency और अवधि रखें। Errors तथा 95th-percentile latency दर्ज करें—इसके नीचे 95% मापे गए requests का समय आता है। हर candidate पर वही scenario दोहराएँ।
Upgrade से पहले बाधा पहचानें
छोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| लोड में दिखा संकेत | क्या जाँचें |
|---|---|
| कम available RAM और लगातार swap-in/out | Workers, database memory और RAM budget |
| व्यस्त CPU और बढ़ती runnable queue | महँगा code path, concurrency और CPU allocation |
| बार-बार अधिक steal time | Host contention या plan की सीमा |
| बढ़ता I/O await और धीमे requests | Queries, disk queue और I/O allowance |
| Local तेज़, बाहरी response धीमा | Region, DNS/TLS और network path |
ये संकेत हैं, अपने आप लागू होने वाले upgrade नियम नहीं। पुराने swap pages मौजूद हो सकते हैं, जबकि अभी swap activity न हो। Database lock CPU खाली होने पर भी request रोक सकता है। App logs और एक ही समय के samples मिलाएँ।
Catalogue import से browsing धीमी हो, पर CPU खाली रहे, तो पहले queries और storage देखें। Workers RAM भरें तो कम workers या अधिक RAM का एक नियंत्रित परीक्षण करें। एक बार में एक बड़ा बदलाव करें।
मापन के साथ पूरा खर्च और recovery जोड़ें
Linux VPS होस्टिंग की तुलना में VM, IPv4, backup storage, transfer, management और tax का एक जैसा हिसाब रखें। नीचे के USD अंक केवल गणित के उदाहरण हैं; वास्तविक offer या India की कीमतें नहीं।
छोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| मासिक मद | उदाहरण A | उदाहरण B |
|---|---|---|
| डिस्क सहित VM | $6 | $8 |
| ज़रूरी IPv4 | $2 | $0 शामिल |
| बैकअप storage | $3 | $2 |
| माना गया transfer | $0 शामिल | $3 |
| Tax से पहले उदाहरण का कुल | $11 | $13 |
Promotion समाप्त होने के बाद का मूल्य और बंद VM की billing पूछें। Disk, reserved IP या snapshot पर अलग charge रह सकता है। Currency, tax treatment और quote की तारीख लिखें। SMTP जैसे outbound नियम provider स्तर पर भी हो सकते हैं; UFW में port खोलना उस रोक को नहीं हटाता।
Recovery console, independent copy और restore की प्रक्रिया जाँचें। Unmanaged service में updates और incidents की ज़िम्मेदारी तय करें। फाइल restore का अभ्यास करें, फिर पहली वेबसाइट का सेटअप पूरा करें।
सवाल-जवाब
2 vCPU वाला VPS कितने visitors संभाल सकता है?
ऐप और workload के बिना भरोसेमंद संख्या नहीं दी जा सकती। Static response, database write और image processing की लागत अलग होती है। अपने stack को तय concurrency पर मापें।
Managed hosting कब चुनें?
शामिल कामों को अपनी टीम की क्षमता से मिलाएँ। Updates, app troubleshooting, backup और restore सहायता का दायरा पूछें; केवल control panel मिलने का मतलब managed service नहीं।