سستی VPS آفر کو کیسے پرکھیں: اصل قیمت اور vCPU

سستے VPS آفر میں کیا شامل نہیں ہوتا

سستی VPS آفر کو الٹی سمت سے پڑھیں، کیونکہ صفحے پر موجود قیمت سب سے کم مفید عدد ہوتی ہے۔ سرور کے اچھا ہونے کا فیصلہ ان تفصیلات سے ہوتا ہے جو listing میں درج نہیں کی جاتیں: vCPU count کے پیچھے oversell ratio، "unlimited" کے پیچھے fair use clause، پہلی مدت کے بعد renewal price، اور یہ کہ backups اور IPv4 address کی فیس الگ سے لی جاتی ہے یا نہیں۔ یہ guide ایک listing کو سطر بہ سطر دیکھتی ہے، پھر آپ کو ایک acceptance test دیتی ہے جسے آپ سرور پر اس وقت تک چلا سکتے ہیں جب تک رقم کی واپسی کا مطالبہ ممکن ہو۔

اس کا مطلب یہ نہیں کہ کم قیمت لازماً دھوکا ہے۔ پرانا hardware، زیادہ گنجان packing، self-service support اور platform redundancy کی کم سطح ہی وہ عوامل ہیں جن سے کم قیمت ممکن ہوتی ہے۔ اصل مقصد یہ جاننا ہے کہ آپ نے کون سا trade-off قبول کیا ہے، اس سے پہلے کہ آپ کے users خود اس کا اثر محسوس کریں۔ ذیل کی تمام کارروائیاں Ubuntu 24.04 پر، August 2026 میں دستیاب packages کے ساتھ چلتی ہیں۔

vCPU، core نہیں ہوتا

vCPU دراصل scheduling slot ہوتا ہے، silicon کا الگ حصہ نہیں۔ KVM (kernel-based virtual machine) میں ہر vCPU، host پر ایک thread ہوتا ہے۔ host scheduler اس thread کی باری آنے پر اسے کسی physical core پر چلاتا ہے۔ ایک host، ایک physical core کے مقابلے میں چار vCPUs فروخت کر سکتا ہے، اور ہر guest پھر بھی nproc میں اپنی پوری تعداد دکھاتا ہے۔ listing میں دی گئی تعداد صرف اس حد کو ظاہر کرتی ہے جس تک آپ وسائل طلب کر سکتے ہیں۔ اس سے یہ معلوم نہیں ہوتا کہ آپ کے لیے کیا مختص ہے۔

oversell ratio سے مراد ہر physical core کے مقابلے میں host کی جانب سے فروخت کیے گئے vCPUs کی تعداد ہے۔ 1:1 پر core صرف آپ کے لیے ہوتا ہے۔ کم قیمت plans میں یہ ratio زیادہ ہوتا ہے، اور اسے تقریباً کبھی شائع نہیں کیا جاتا۔ اس لیے ایسی listing کو shared سمجھیں جس میں "dedicated core" یا "dedicated vCPU" درج نہ ہو۔ Shared وسائل زیادہ تر کاموں کے لیے کافی ہوتے ہیں، کیونکہ زیادہ تر servers زیادہ وقت idle رہتے ہیں۔ مسئلہ اس وقت شروع ہوتا ہے جب آپ کا مصروف وقت دوسرے تمام صارفین کے مصروف وقت سے ٹکرا جائے۔

آپ guest کے اندر سے اس کا اثر ناپ سکتے ہیں۔ جب آپ کا vCPU چلنے کے لیے تیار ہو، لیکن host physical core کسی دوسرے guest کو دے دے، تو اس انتظار کو steal time کہا جاتا ہے۔ یہ vmstat کے st column اور top میں %st کے طور پر شمار ہوتا ہے۔ Steal time آپ کے اپنے metrics میں noisy neighbour کے ظاہر ہونے کا طریقہ ہے، اور اس guide میں یہ سب سے مفید عدد ہے، کیونکہ listing اسے جعلی نہیں بنا سکتی۔

Dedicated core دوسرے طریقوں سے پھر بھی shared ہوتا ہے۔ Memory bandwidth، last level cache اور storage path پورے host کے لیے مشترک ہوتے ہیں۔ "Dedicated vCPU" variance کے سب سے بڑے ذریعے کو ختم کرتا ہے۔ یہ تمام variance ختم نہیں کرتا۔

lscpu سے CPU model بھی دیکھیں۔ دو plans میں "4 vCPU" درج ہو سکتا ہے، لیکن ان کی single-thread speed میں دو گنا فرق ہو سکتا ہے، کیونکہ ایک host کی CPU generation کئی نسلیں پرانی ہو سکتی ہے۔ کم قیمت پر پرانا silicon build agent کے لیے مناسب سودا ہے، لیکن checkout page کے لیے نہیں۔

"Unlimited bandwidth" سے مراد کم از کم چار مختلف مصنوعات ہو سکتی ہیں۔

Traffic کو چار طریقوں سے بیان کیا جاتا ہے، اور یہ ایک دوسرے کا متبادل نہیں ہیں۔

• Metered allowance۔ Listing میں ایک مقدار دی جاتی ہے، مثلاً "2 TB per month" یا اسی طرح کی کوئی مقدار۔ اہم بات یہ ہے کہ اس حد کے بعد کیا ہوتا ہے: ہر اضافی TB پر overage charge، یا مہینہ ختم ہونے تک رفتار کو بہت کم کر دینا۔ اس کی وضاحت پہلے حاصل کریں۔
• Fair use clause والا unmetered plan۔ Traffic شمار نہیں کیا جاتا، اور acceptable use policy حد کو اعداد کے بجائے الفاظ میں بیان کرتی ہے۔ اس دستاویز میں "fair use"، "sustained"، "excessive" اور "abuse" تلاش کریں۔
• Port speed cap۔ 100 Mbit/s port آپ کو عملی طور پر محدود کرتا ہے، خواہ traffic policy کچھ بھی کہتی ہو۔
• آخری دو صورتوں کا امتزاج: سست port پر unmetered traffic۔ سستے plans میں یہ سب سے عام صورت ہے۔ اگر آپ port speed پڑھ لیں تو یہ ایک واضح پیشکش ہے۔

[
  {
    "label": "100 Mbit/s",
    "tb_ceiling_30d": 32,
    "hours_per_tb": 22.2
  },
  {
    "label": "200 Mbit/s",
    "tb_ceiling_30d": 65,
    "hours_per_tb": 11.1
  },
  {
    "label": "500 Mbit/s",
    "tb_ceiling_30d": 162,
    "hours_per_tb": 4.4
  },
  {
    "label": "1 Gbit/s",
    "tb_ceiling_30d": 324,
    "hours_per_tb": 2.2
  }
]

Port speed ایک قطعی حد ہوتی ہے، اور حساب سادہ ہے۔ 100 Mbit/s، 12.5 megabytes per second کے برابر ہے، اس لیے اس port کو 30 دن تک مکمل رفتار پر چلانے سے تقریباً 32 TB منتقل ہوں گے۔ اسی 30 دن میں 1 Gbit/s port سے 324 TB منتقل ہوں گے۔ یہاں TB سے مراد 10^12 bytes ہے، اور hosts اسی unit میں billing کرتے ہیں۔ یہ حساب ہے، پیمائش نہیں؛ کوئی حقیقی server پورے مہینے اپنے port کو مسلسل مکمل رفتار پر نہیں چلاتا۔

دوسرا column وہ ہے جو plans کے درمیان فرق پیدا کرتا ہے۔ ایک terabyte منتقل کرنے میں 100 Mbit/s port پر تقریباً 22.2 hours اور gigabit port پر 2.2 hours لگتے ہیں۔ اگر آپ کا recovery plan یہ ہے کہ "backup download کریں اور دوبارہ شروع کریں"، تو یہی عدد آپ کا recovery time ہے۔

اس specification line میں دو مزید تفصیلات پوشیدہ ہیں۔ "1 Gbit/s shared" کا مطلب ہے کہ port دوسرے guests کے ساتھ مشترک ہے، اس لیے اوپر دی گئی حد بہترین صورت ہے، ضمانت نہیں۔ کچھ hosts traffic کی billing کل volume کے بجائے sampled rate کے 95th percentile پر کرتے ہیں۔ اس صورت میں مستقل load کی قیمت، وقفے وقفے سے آنے والے spiky load سے بہت کم ہو سکتی ہے۔

Plan کچھ بھی کہتا ہو، اپنا استعمال خود measure کریں۔ vnstat interface counters پڑھتا ہے اور history محفوظ رکھتا ہے۔

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -d
vnstat -m

Install کے فوراً بعد vnstat Not enough data available yet. دکھاتا ہے، کیونکہ اس کے database میں کوئی samples نہیں ہوتے۔ اگلے دن دوبارہ دیکھیں؛ vnstat -m آپ کو monthly total دے گا، جس کا موازنہ آپ کے paid allowance سے کیا جا سکتا ہے۔

کیا NVMe کا دعویٰ درست ہے، اور کیا آپ اسے جانچ سکتے ہیں؟

lsblk -d -o NAME,ROTA,SIZE,MODEL

ROTA کی قدر 0 ہونے کا مطلب ہے کہ guest کو بتایا گیا تھا کہ device rotational نہیں ہے۔ یہ قدر hypervisor سے آتی ہے، اس لیے یہ اس بات کی وضاحت کرتی ہے جو host ظاہر کرتا ہے، نہ کہ اندر موجود media کی۔ MODEL column عموماً کسی virtio disk، مثلاً /dev/vda، کے لیے خالی ہوتا ہے، جبکہ SCSI سے منسلک disk کے لیے عمومی QEMU HARDDISK دکھاتا ہے۔ آپ virtual disk دیکھ رہے ہیں، اس لیے اس کا label کچھ ثابت نہیں کرتا۔

جس property کو جانچنا مفید ہے وہ latency ہے، اور اصل فرق local NVMe اور network attached volume کے درمیان ہے۔ Network volume بڑی sequential throughput figure ظاہر کر سکتا ہے اور پھر بھی سست محسوس ہو سکتا ہے، کیونکہ throughput بہت سی requests کے زیرِ التوا ہونے پر ناپی جاتی ہے، جبکہ database ایک وقت میں ایک چھوٹی write کا انتظار کرتا ہے۔ Latency کے لیے queue depth 1 پر measurement کریں، پھر IOPS (input/output operations per second) کے لیے زیادہ گہری queue استعمال کریں۔

sudo apt install -y fio
fio --name=lat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=1 --numjobs=1 --runtime=60 --time_based --group_reporting
fio --name=iops --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
rm -f fiotest

clat percentiles block پڑھیں، خاص طور پر 99.00th line۔ یہ completion latency ہے جو آپ کی requests کے سب سے سست ایک فیصد حصے نے دیکھی، اور صارف کو یہی تاخیر stall کے طور پر محسوس ہوتی ہے۔ عمومی رہنمائی کے طور پر، queue depth 1 پر local NVMe سینکڑوں microseconds میں جواب دیتا ہے، جبکہ network attached volume milliseconds میں جواب دیتا ہے۔ کسی ایک شائع شدہ figure پر بھروسا کرنے کے بجائے اپنی دونوں runs کا موازنہ کریں، اور دن کے مختلف اوقات میں یہ جوڑا تین مرتبہ چلائیں، کیونکہ دوسرے tenants کے ساتھ shared disk کا رویہ 03:00 اور 20:00 پر مختلف ہو سکتا ہے۔

fio پہلے 1 GB file disk پر رکھتا ہے، اس لیے disk پر گنجائش چھوڑیں، اور یاد رکھیں کہ test اس plan پر لاگو IOPS allowance استعمال کرتا ہے۔ جب آپ کو صرف فوری reading چاہیے تو ioping -c 20 . ایک ہی line میں latency فراہم کرتا ہے۔ Benchmark اسی وقت مفید ہے جب آپ اسے دوبارہ چلا سکیں، اس لیے exact command lines اور output کو تاریخ کے ساتھ محفوظ کریں۔

کیا شامل ہے، اور کن چیزوں کے اضافی اخراجات ہوتے ہیں

• IPv4۔ عموماً ایک address شامل ہوتا ہے۔ کچھ سستے plans آپ کو NAT (network address translation) کے پیچھے shared address دیتے ہیں، جس کے ساتھ چند forwarded ports ہوتے ہیں۔ اس کا مطلب ہے کہ آپ اپنے کسی بھی server کو port 443 پر نہیں چلا سکتے۔ ip -4 addr show scope global اور curl -4 https://icanhazip.com سے جانچ کریں۔ دونوں کے مختلف جواب آنے کا مطلب ہے کہ آپ NAT کے پیچھے ہیں۔
• IPv6۔ routed /64 آپ کو containers اور ہر اس چیز کے لیے addresses دیتا ہے جسے آپ باہر سے قابل رسائی بنانا چاہتے ہیں۔ ایک /128 صرف outbound traffic اور بہت محدود دیگر استعمالات کے لیے کافی ہوتا ہے۔
• Backups۔ Automatic backups عموماً paid add-on ہوتے ہیں۔ Snapshots اکثر free ہوتے ہیں، لیکن snapshot اسی infrastructure پر رہتا ہے جہاں وہ disk موجود ہوتی ہے جس کی copy بنائی گئی ہے۔ اس لیے یہ آپ کو اپنی غلطیوں سے بچاتا ہے، host کے ضائع ہونے سے نہیں۔ Plan میں کچھ بھی شامل ہو، ایک copy box سے باہر ضرور رکھیں۔
• DDoS handling۔ بہت سے hosts volumetric attack (distributed denial of service) کی صورت میں آپ کے IP address کو ایک مقررہ مدت کے لیے null route کر دیتے ہیں۔ Server درست حالت میں رہتا ہے، لیکن internet سے قابل رسائی نہیں رہتا۔ معلوم کریں کہ trigger threshold کیا ہے اور null route کتنی دیر برقرار رہتا ہے۔
• Support scope۔ Unmanaged plan میں system administrator آپ ہوتے ہیں، جبکہ host کی ذمہ داری hypervisor اور network تک محدود رہتی ہے۔ یکساں specifications والے دو plans کے درمیان حقیقی لاگت کا سب سے بڑا فرق یہی ہوتا ہے۔
• Licences اور panels۔ Control panel، commercial operating system یا mail add-on کی ماہانہ قیمت خود server سے زیادہ ہو سکتی ہے۔

آپ کس قسم کی virtualization خرید رہے ہیں؟

systemd-detect-virt

kvm یا qemu سے مراد full virtualization ہے: آپ کی اپنی kernel ہوتی ہے اور آپ اس میں اپنی پسند کے modules load کر سکتے ہیں۔ lxc، lxc-libvirt یا openvz سے مراد ایسا container ہے جو host kernel استعمال کرتا ہے۔ none سے مراد bare metal ہے۔

مشترکہ kernel کا فرق عملی صورت میں نمایاں ہوتا ہے۔ sudo modprobe wireguard ناکام ہو جاتا ہے، اور ip link add dev wg0 type wireguard، RTNETLINK answers: Operation not supported واپس کرتا ہے، کیونکہ container ایسا kernel module load نہیں کر سکتا جسے host نے load نہ کیا ہو۔ lxcfs موجود نہ ہو تو free -h آپ کی اپنی memory کے بجائے host کی memory رپورٹ کر سکتا ہے، اس لیے monitoring میں ایسے اعداد آتے ہیں جن کا آپ کے server سے تعلق نہیں ہوتا۔ Swap اکثر دوسرے containers کے ساتھ مشترکہ ہوتی ہے، اور اپنے VPS کے اندر virtual machines چلانا بالکل ممکن نہیں ہوتا۔ Container plans ایک وجہ سے سستے ہوتے ہیں، اور static site یا چھوٹی application کے لیے یہ اب بھی درست انتخاب ہیں۔

تجدید کی قیمت کیا ہے؟

تشہیری قیمت اکثر صرف پہلی مدت پر لاگو ہوتی ہے۔ آرڈر کے صفحے پر "renews at" کے الفاظ تلاش کریں، اور یہ بھی دیکھیں کہ رعایت کس مدت کے ساتھ منسلک ہے۔ ایک سال تک جاری رہنے والی رعایت اور پورے plan کی مدت کے لیے برقرار رہنے والی رعایت، ایک ہی پہلے invoice کے پیچھے دو مختلف مصنوعات ہوتی ہیں۔

Refund کی شرائط بھی اسی احتیاط سے پڑھیں۔ دیکھیں کہ money-back window کتنی مدت تک رہتی ہے، یہ آرڈر کے وقت شروع ہوتی ہے یا provisioning کے وقت، extra IP addresses جیسی add-ons کے لیے refund ملتا ہے یا نہیں، اور annual prepayment کی رقم pro rata واپس ہوتی ہے یا نہیں۔ پھر renewal date سے ایک ہفتہ پہلے کے لیے اپنے calendar میں reminder لگائیں، کیونکہ سروس چھوڑنے کا کم خرچ وقت invoice جاری ہونے سے پہلے ہوتا ہے۔

بعد میں provider تبدیل کرنا بھی مفت نہیں ہوتا۔ چند سو gigabytes کا data منتقل کرنا، configuration دوبارہ بنانا، DNS (domain name system) کے time to live values کے ختم ہونے کا انتظار کرنا، اور mail server کے لیے IP reputation دوبارہ بنانا، مجموعی طور پر پورا weekend لے سکتا ہے۔ جب کوئی saving پُرکشش لگے تو اس weekend کی لاگت بھی حساب میں شامل کریں۔ ایک سال میں VPS کی اصل لاگت وہ figure ہے جس کا موازنہ کرنا چاہیے، نہ کہ پہلے مہینے کی قیمت۔

تیس منٹ کا قبولیت ٹیسٹ

کسی بھی چیز کو migrate کرنے سے پہلے نئے box پر یہ ٹیسٹ چلائیں، اور اس وقت تک چلائیں جب refund window کھلی ہو۔ پہلے اسے secure کریں: نئے VPS پر پہلے دس منٹ میں user account، keys اور firewall کا احاطہ کیا گیا ہے۔ پھر tools install کریں۔

sudo apt update
sudo apt install -y sysbench fio ioping sysstat stress-ng vnstat mtr-tiny curl

چیک 1: انہوں نے حقیقت میں مجھے کیا دیا ہے؟

systemd-detect-virt
nproc
lscpu | grep -E 'Model name|MHz|Hypervisor'
free -h
lsblk -d -o NAME,ROTA,SIZE,MODEL
ip -4 addr show scope global
curl -4 -s https://icanhazip.com

آپ کو virtualization type، CPU model اور memory figure نظر آنی چاہیے، جو آپ کے خریدے گئے plan سے چند فیصد کے اندر ہو۔ free -h کا plan میں فروخت کی جانے والی RAM سے کہیں زیادہ RAM report کرنا bonus نہیں، بلکہ lxcfs کے بغیر container کی علامت ہے۔ curl سے ملنے والا public address اگر کبھی ip -4 addr میں ظاہر نہ ہو تو اس کا مطلب ہے کہ IPv4 address shared ہے۔

چیک 2: ایک thread کتنی تیز ہے، اور load کے دوران steal کتنا ہے؟

sysbench cpu --cpu-max-prime=20000 --threads=1 run

events per second line محفوظ کریں۔ Single-thread speed اس بات کا تعین کرتی ہے کہ page کتنی تیزی سے render ہوتا ہے اور build مکمل ہونے میں کتنا وقت لگتا ہے۔ یہی وہ number ہے جس میں سستے plans سب سے زیادہ مختلف ہوتے ہیں۔ اب ہر vCPU پر load ڈالیں اور دیکھیں کہ scheduler حقیقت میں آپ کو کیا CPU time دیتا ہے۔

stress-ng --cpu 0 --timeout 300s &
vmstat 1 30
mpstat -P ALL 1 10

--cpu 0 ہر online CPU کے لیے ایک worker شروع کرتا ہے۔ vmstat میں st column اور mpstat میں %steal دیکھیں۔ Shared plan پر کبھی کبھار single digits معمول کی بات ہیں۔ اگر steal کئی منٹ تک double digits میں رہے تو physical cores پر ضرورت سے زیادہ load ہے، اس لیے آپ کا کام دوسرے tenant کے کام کے پیچھے queue میں ہے۔ Load جاری رکھتے ہوئے sysbench دوبارہ چلائیں۔ اگر single-thread score نمایاں طور پر کم ہو جائے تو اس کا مطلب ہے کہ آپ کے vCPUs ایک دوسرے سے compete کر رہے ہیں۔ عموماً اس کا مطلب ہوتا ہے کہ وہ الگ cores کے بجائے ایک core پر sibling threads ہیں۔ Near-zero steal کے ساتھ کم score دوسری صورت کی علامت ہے: host نے CPU cap لگائی ہوئی ہے، جسے آپ guest کے اندر سے براہ راست نہیں دیکھ سکتے۔

چیک 3: queue depth 1 پر disk کا برتاؤ کیسا ہے؟

NVMe section میں دی گئی دونوں fio commands چلائیں اور دونوں نتائج محفوظ کریں: queue depth 1 پر 99th percentile latency اور depth 32 پر IOPS۔ پھر writes بھی check کریں، کیونکہ بہت سے volumes اس سمت میں کہیں زیادہ سست ہوتے ہیں۔

fio --name=wlat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --runtime=30 --time_based --group_reporting
rm -f fiotest

dd sequential figure وہ number ہے جسے listing میں quote کرنا پسند کیا جاتا ہے، لیکن یہ وہ کم مفید number ہے جسے آپ collect کر سکتے ہیں۔ اس کی وجہ یہ ہے کہ database یا مصروف web application اپنا زیادہ تر وقت sequential streaming میں نہیں گزارتا۔ اگر آپ comparison چاہتے ہیں تو اسے بھی collect کریں۔ اصل فیصلہ latency کی بنیاد پر کریں۔

چیک 4: آپ کے users کے مقام سے network کیسا دکھائی دیتا ہے؟

پہلے VPS پر کوئی بڑی file download کریں۔

curl -o /dev/null -w 'in: %{speed_download} bytes/s\n' https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

اس سے صرف آپ کے server تک آنے والے ایک path کا test ہوتا ہے، اس کے علاوہ کچھ نہیں۔ اہم direction وہ ہے جسے آپ کے users استعمال کرتے ہیں، اس لیے file serve کریں اور اسے ان کے قریب موجود machine سے download کریں۔

fallocate -l 100M /var/tmp/100mb.bin
python3 -m http.server 8080 --directory /var/tmp

پھر اپنے audience کے قریب موجود laptop یا server سے:

curl -o /dev/null -w 'down: %{speed_download} bytes/s\n' http://YOUR_SERVER_IP:8080/100mb.bin
mtr --report --report-cycles 50 YOUR_SERVER_IP

یہ test کرتے وقت firewall میں port 8080 کھلا ہونا ضروری ہے۔ اس کے بعد اسے بند کریں، file delete کریں، اور Ctrl+C سے Python server روک دیں۔ mtr کے output میں آخری line کا loss column پڑھیں۔ اگر کسی intermediate hop پر loss ہو لیکن destination پر نہ ہو تو یہ معمول کی بات ہے، کیونکہ routers ICMP (internet control message protocol) replies کو، جنہیں mtr count کرتا ہے، کم priority پر دیتے ہیں۔ اس کا مطلب یہ نہیں کہ آپ کے traffic میں loss ہے۔ آخری line پر loss حقیقی ہے۔

Network test اپنے users کے peak hour کے دوران دوبارہ کریں۔ 02:00 پر لیا گیا ایک sample آپ کو صرف خاموش network کے بارے میں بتاتا ہے۔

چاروں نتائج date کے ساتھ ایک file میں محفوظ کریں، پھر ایک ماہ بعد انہیں دوبارہ چلائیں۔ جو plan day one پر ٹھیک اور week six میں سست ہو، اس کا مطلب ہے کہ host بھر چکا ہے۔ Day one کے numbers محفوظ ہونے سے آپ یہ جان سکتے ہیں؛ ورنہ صرف اندازہ لگانا پڑتا ہے۔

جب سستا VPS موزوں انتخاب ہو

کم قیمت کے بدلے حقیقی سہولیات ملتی ہیں، اور کچھ حقیقی سمجھوتے بھی کرنے پڑتے ہیں۔ پرانے CPUs، زیادہ oversell ratio، سست network storage، self-service support اور کمزور redundancy ہی قیمت کم رکھنے کی وجہ ہوتے ہیں۔ اپنے کام کی ضروریات کے مطابق ان کا جائزہ لیں۔

سستا VPS development box، CI runner، VPN endpoint، monitoring node، backup target یا static site کے لیے موزوں ہے۔ یہ تمام کام ایک سست منٹ برداشت کر سکتے ہیں۔ لیکن جہاں latency ہی سروس کی بنیادی قدر ہو، وہاں سستا VPS اچھا سودا نہیں ہوتا؛ مثلاً checkout page، interactive API، game server یا وہ database جس کے جواب کا کوئی دوسرا service انتظار کرتا ہو۔ اوپر دیا گیا test بتاتا ہے کہ آپ نے کس قسم کا VPS خریدا ہے، اور یہ بات اس وقت معلوم ہو جاتی ہے جب اس کا جواب حاصل کرنا ابھی بھی مفت ہوتا ہے۔

FAQ

سستے VPS offer میں vCPU سے کیا مراد ہے؟

vCPU ایک virtual processor ہے جو آپ کے guest کو دیا جاتا ہے۔ ضرورت پڑنے پر host scheduler اسے physical core پر چلنے والے thread سے map کرتا ہے۔ یہ CPU time طلب کرنے کی اجازت ہے، reserved hardware نہیں، سوائے اس کے کہ listing میں "dedicated core" یا "dedicated vCPU" لکھا ہو۔ Hosts کے پاس موجود cores سے زیادہ vCPUs فروخت کرتے ہیں، اور یہ ratio عموماً شائع نہیں کیا جاتا، اس لیے اسے measure کریں۔ stress-ng --cpu 0 --timeout 300s چلائیں اور vmstat 1 میں st column دیکھیں۔ اگر steal مسلسل double digits میں ہو تو اس کا مطلب ہے کہ آپ ان cores کے لیے انتظار کر رہے ہیں جنہیں دوسرے guests استعمال کر رہے ہیں۔

کیا "unlimited bandwidth" کا واقعی مطلب unlimited ہوتا ہے؟

نہیں، اور یہ limit عموماً plan description کے علاوہ دو جگہ موجود ہوتی ہے۔ acceptable use policy الفاظ میں fair use limit مقرر کرتی ہے، جبکہ port speed bytes میں hard ceiling مقرر کرتی ہے۔ 100 Mbit/s port حتیٰ کہ full rate پر بھی 30 دن میں تقریباً 32 TB سے زیادہ منتقل نہیں کر سکتا، اس لیے port speed پوچھیں اور policy میں "fair use" اور "sustained" کے الفاظ تلاش کریں۔ پھر vnstat -m سے واقعی بھیجے گئے data کو track کریں اور اسے allowance کے ساتھ compare کریں۔

میں کیسے معلوم کر سکتا ہوں کہ میرا VPS واقعی NVMe استعمال کرتا ہے؟

آپ guest کے اندر سے physical media کی تصدیق نہیں کر سکتے، کیونکہ lsblk صرف وہی رپورٹ کرتا ہے جو hypervisor advertise کرتا ہے: 0 کا ROTA اور خالی یا generic model string۔ آپ جس چیز کو measure کر سکتے ہیں وہ system کا behaviour ہے۔ --iodepth=1 پر --direct=1 کے ساتھ fio چلائیں اور 99.00th percentile completion latency پڑھیں۔ Local NVMe سینکڑوں microseconds میں جواب دیتا ہے، جبکہ network attached volume milliseconds میں جواب دیتا ہے، حتیٰ کہ اس کی sequential throughput متاثر کن نظر آئے۔ دن کے مختلف اوقات میں یہ test چند بار دہرائیں، کیونکہ shared disk 03:00 اور 20:00 پر یکساں نہیں ہوتی۔

refund window بند ہونے سے پہلے مجھے کیا test کرنا چاہیے؟

چار چیزیں، اسی ترتیب سے۔ box حقیقت میں کیا ہے، یہ systemd-detect-virt، lscpu اور free -h سے معلوم کریں۔ single thread speed، sysbench cpu --cpu-max-prime=20000 --threads=1 run سے۔ full load کے دوران steal time، vmstat 1 کے ذریعے watched stress-ng --cpu 0 سے۔ disk latency، queue depth 1 پر fio سے۔ پھر اپنے users کے قریب موجود machine سے mtr اور box سے serve کی جانے والی file کے download کے ذریعے network measure کریں۔ یہ سب کرنے کے لیے 30 minutes کافی ہیں، اور کسی چیز کو migrate کرنے سے پہلے test کرنے پر refund window آپ کے لیے leverage کے طور پر برقرار رہتی ہے۔