Linux VPS پر اپنے ایپ کا بوجھ ناپیں
Linux VPS کا انتخاب اپنے ایپ کی ضروریات سے شروع کریں: آپریٹنگ سسٹم، runtime، architecture اور بحالی کا طریقہ۔ پھر ایک ہی ایپ اور کام کے بوجھ سے امیدوار منصوبے آزمائیں۔ یہاں ناپنے کا طریقہ ہے، کسی provider کی درجہ بندی یا تیار performance benchmark نہیں۔
VPSuntu · تازہ کاری · تقریباً 7 منٹ
اس مضمون میں
پہلے کام اور قابل قبول حدود لکھیں
لینکس وی پی ایس پر web server، runtime، database، cache اور background workers ایک ہی وسائل بانٹتے ہیں۔ Import، image processing اور backup کے وقت ان کا بوجھ اکٹھا ہو سکتا ہے۔ یہ بھی طے کریں کہ مشین سیکھنے، staging یا گاہکوں کے لیے ہے اور کتنی دیر بند رہنا قابل قبول ہے۔
مثال کے طور پر Nginx، ایک application service، PostgreSQL اور scheduled import والا چھوٹا catalogue لیں۔ 2 vCPU اور 4 GB RAM ایک ابتدائی تجربہ ہو سکتے ہیں؛ یہ آزمائی ہوئی گنجائش نہیں۔ نمائندہ records اور uploads استعمال کریں، غیر ضروری test میں گاہکوں کا نجی ڈیٹا نہ رکھیں۔ ابتدائی وسائل کی مثالیں کام کے حساب سے منتخب کریں۔
موازنہ ایک جیسی شرائط پر کریں
ہر امیدوار پر ایک ہی app build، database copy، cache اور worker count رکھیں۔ Ubuntu release، architecture اور region درج کریں۔ قریب data centre یا مختلف software کو hardware کی برتری نہ سمجھیں۔ پاکستان میں اپنے اصل صارفین اور database تک response ناپیں؛ رابطے کا پتہ server location نہیں ہے۔
چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔
| کیا درج کریں | فیصلے پر اثر |
|---|---|
| CPU allocation اور fair-use | Shared، dedicated اور burstable CPU کی حدود مختلف ہیں |
| RAM اور swap | تمام services ایک memory budget استعمال کرتی ہیں |
| ڈسک کی گنجائش اور I/O | خالی جگہ اور جواب کا وقت الگ چیزیں ہیں |
| Region اور dependencies | دور database ہر request میں تاخیر لا سکتا ہے |
| Resize اور restore | تبدیلی یا بحالی میں downtime ہو سکتا ہے |
| Billing unit اور اضافی خدمات | برابر VM قیمت کا مجموعی بل مختلف ہو سکتا ہے |
Linux VPS سرور میں vCPU کی تعداد مستقل CPU گنجائش ثابت نہیں کرتی۔ NVMe لکھا ہونا I/O allowance نہیں بتاتا۔ مسلسل workload کی اجازت اور بڑی کی گئی disk دوبارہ چھوٹی کرنے کی شرط provider سے معلوم کریں۔
سرور پر ابتدائی پیمائش لیں
Ubuntu server پر available memory اور disk space درج کریں۔ iostat کے لیے sysstat install ہوتا ہے۔ Workload چلتے وقت sampling commands الگ terminals میں چلائیں؛ idle مشین کا مختصر sample اصل بوجھ کا ٹیسٹ نہیں۔
free -h
df -h /
sudo apt update
sudo apt install sysstat
vmstat 1 11
iostat -xz -y 1 10vmstat کی پہلی CPU/activity سطر boot سے اب تک کا خلاصہ ہے؛ اس کے بعد کی ایک سیکنڈ والی سطریں دیکھیں۔ free میں available پڑھیں، صرف free نہیں: Linux کچھ cache واپس لے سکتا ہے۔ iostat کا -y ابتدائی مجموعی رپورٹ چھوڑتا ہے۔
اصل مشاہدے کی مثال: اس static site کے origin پر 24 ستمبر 2026 کو ایک visible logical CPU اور 957 MiB memory دیکھی گئی۔ اسی snapshot میں 59 MiB free مگر 358 MiB available تھی، اور control panel سمیت دوسری services بھی تھیں۔ یہ free/available کا فرق ہے، visitor capacity یا load benchmark نہیں۔
Sample کے ساتھ وقت اور scenario لکھیں۔ Import اور backup کے دوران disk growth دیکھیں۔ df -h / صرف root filesystem بتاتا ہے؛ database کا الگ volume ہو تو اسے بھی جانچیں۔
صارف کا اصل کام آزمائیں
اپنی staging میں browsing، search، login اور نمائندہ write operation چلائیں۔ Cache کے ساتھ اور بغیر requests اور background jobs شامل کریں۔ پہلے قابل قبول response time اور error rate طے کریں۔
صارفین کے قریب کسی client سے status، first byte اور مکمل request کا وقت ناپ سکتے ہیں۔ Hostname/path اپنی staging سے بدلیں؛ درج اوقات 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 اور اصل workflow دہرانے والا script استعمال کریں۔ Request rate، concurrency، دورانیہ، dataset اور cache state درج کریں۔ Errors اور 95th-percentile response time دیکھیں: وہ حد جس سے 95 فیصد مشاہدہ شدہ requests کم وقت لیتی ہیں۔ اسی دوران VM دیکھیں اور ہر امیدوار پر ایک ہی scenario دہرائیں۔
وسائل بڑھانے سے پہلے رکاوٹ پہچانیں
چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔
| بوجھ کے دوران علامت | اگلی جانچ |
|---|---|
| Available RAM کم اور مسلسل swap-in/out | Workers، database memory اور RAM budget |
| CPU مصروف اور runnable queue بڑھ رہی ہے | مہنگے code paths، concurrency اور CPU allocation |
| بار بار زیادہ steal time | Host scheduling contention یا plan limit |
| I/O await بڑھ رہا ہے اور requests سست ہیں | Queries، disk queue اور I/O allowance |
| Local جواب تیز، بیرونی جواب سست | Region، DNS/TLS اور network path |
یہ اشارے ہیں، خودکار upgrade کا حکم نہیں۔ Swap میں پرانے inactive pages ہو سکتے ہیں؛ موجودہ activity دیکھیں۔ Disk await میں queue اور service time دونوں شامل ہیں۔ Database lock خالی CPU کے باوجود request روک سکتا ہے۔ Logs کو اسی وقت کے samples سے ملائیں۔
Catalogue import کے ساتھ browsing سست ہو اور CPU فارغ ہو تو queries اور storage پہلے دیکھیں۔ Workers RAM بھر دیں تو اسی workload میں کم workers یا زیادہ RAM آزمائیں۔ ایک وقت میں ایک بڑی چیز بدلیں۔
Linux VPS ہوسٹنگ کا پورا خرچ لکھیں
نیچے USD اعداد صرف حساب سمجھانے کی فرضی مثالیں ہیں، دستیاب offers یا پاکستان کی قیمتیں نہیں۔ دونوں میں ایک VM، ضروری IPv4، یکساں backup اور transfer فرض ہیں؛ tax اور management شامل نہیں۔
چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔
| ماہانہ مد | مثال A | مثال B |
|---|---|---|
| ضروری disk سمیت VM | $6 | $8 |
| ضروری IPv4 | $2 | $0 شامل |
| Backup storage | $3 | $2 |
| فرض کردہ transfer | $0 شامل | $3 |
| Tax سے پہلے کل | $11 | $13 |
پہلی مثال کی $6 VM کا کل $11 ہے۔ اپنا حساب اصل units، allowance اور اضافی استعمال کی شرح سے بنائیں۔ Currency، tax اور quote date درج کریں۔ Promotion ختم ہونے کے بعد renewal دیکھیں۔ بند VM کی disks یا reserved addresses قابل ادائیگی رہ سکتے ہیں؛ stop، delete اور release الگ عمل ہیں۔
نیٹ ورک اور بحالی بھی انتخاب کا حصہ ہیں
Inbound کے ساتھ outbound rules پوچھیں۔ Mail کے لیے SMTP restrictions اور relay کی شرائط دیکھیں؛ UFW میں port کھولنا provider کی روک نہیں ہٹاتا۔ ایپ اور database کا باہمی فاصلہ بھی VM کے نتیجے کو متاثر کرتا ہے۔
Recovery console تلاش کریں، بیک اپ باہر رکھیں اور الگ جگہ restore کریں۔ Snapshot کی retention اور failure domain پوچھیں۔ Unmanaged service میں updates اور incidents کی ذمہ داری اپنی سمجھیں، جب تک معاہدہ کچھ اور نہ کہے۔
چھوٹی static site کے لیے فائل بحالی کی مشق کریں۔ Database کے لیے consistent backup کا الگ طریقہ چاہیے۔ وہ امیدوار منتخب کریں جو workload، growth اور recovery کی تحریری ضرورت پوری کرے؛ پھر پہلی ویب سائٹ کا سیٹ اپ کریں۔
سوال جواب
2 vCPU کتنے visitors سنبھال سکتے ہیں؟
ایپ اور workload کے بغیر قابل اعتماد تعداد نہیں بتائی جا سکتی۔ Cached static جواب اور database write کا خرچ مختلف ہے۔ اصل stack، request pattern اور concurrency ناپیں۔
Managed hosting کب مناسب ہے؟
شامل کاموں کو اپنی ٹیم کی صلاحیت سے ملائیں۔ Updates، app troubleshooting، backup اور restore assistance کا واضح دائرہ اور قیمت پوچھیں۔