{"id":385,"date":"2026-02-08T02:00:26","date_gmt":"2026-02-08T02:00:26","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=385"},"modified":"2026-10-22T22:04:11","modified_gmt":"2026-10-22T22:04:11","slug":"windows-vps-virtual-private-server-buyer-guide","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/windows-vps-virtual-private-server-buyer-guide\/","title":{"rendered":"Which VPS Specs Actually Predict Performance (and the Five You Can Measure)"},"content":{"rendered":"\n

Cost per gigabyte of RAM is the wrong metric for a VPS, because the RAM itself is not what you are buying. What you are buying is a share of the host’s coherence domain: the last-level cache, the memory controller, and the physical socket the scheduler is willing to keep your vCPUs on. On a 2-socket host with 64+ cores, a 2-vCPU guest can be placed across a socket boundary and pay a cache-line transfer on every shared-memory access \u2014 a cost that never appears in top<\/code> but shows up as a 30\u201350% throughput difference against an identical guest placed inside one NUMA node.<\/p>\n\n\n\n

This page covers how to detect that, and which spec axes actually predict performance. For the plan-tier breakdown that maps these axes to price bands, see our VPS plan sizing guide by workload<\/a>.<\/p>\n\n\n\n

The Specs That Predict Nothing<\/h2>\n\n\n\n
Advertised spec<\/th>Predictive power<\/th>Why<\/th><\/tr><\/thead>
vCPU count<\/td>Low<\/td>Share of a core, a full core and a pinned core all read “2 vCPU”<\/td><\/tr>
RAM size<\/td>Medium<\/td>Real, but usually the easiest axis to satisfy<\/td><\/tr>
Disk size<\/td>None<\/td>Unrelated to IOPS, which depends on backing store and tier<\/td><\/tr>
“NVMe”<\/td>Low<\/td>Local NVMe, network NVMe and tiered NVMe all use the same word<\/td><\/tr>
Bandwidth “unmetered”<\/td>Low<\/td>Port speed and traffic allowance are separate quantities<\/td><\/tr>
CPU model string<\/td>High<\/td>Generation determines IPC, AVX-512 availability and memory speed<\/td><\/tr>
Guaranteed \/ dedicated CPU<\/td>High<\/td>Changes the scheduler behaviour under host contention<\/td><\/tr>
Provider’s region and upstream<\/td>High<\/td>Determines RTT to your users and whether the path is direct<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Axis 1: Is the vCPU a Core or a Share?<\/h2>\n\n\n\n

Three products look identical on an order page. The difference shows up only under contention, so measure it by loading all your vCPUs and watching steal and frequency together.<\/p>\n\n\n\n

# Load every vCPU for 120s\nnproc --all\nsudo apt install -y stress-ng sysstat\nstress-ng --cpu $(nproc) --cpu-method matrixprod --timeout 120s &\n\n# In another shell\nvmstat 5 24 | awk 'NR>2{print $13,$14,$15,$16}'\ngrep -m1 'model name' \/proc\/cpuinfo; lscpu | grep -E 'MHz|Socket|NUMA'<\/code><\/pre>\n\n\n\n
Steal (st)<\/th>us+sy<\/th>Interpretation<\/th><\/tr><\/thead>
0\u20132%<\/td>~200% on 2 vCPU<\/td>Dedicated cores or a very quiet host<\/td><\/tr>
3\u20138%<\/td>~190%<\/td>Oversubscribed but well managed \u2014 usually fine<\/td><\/tr>
10\u201325%<\/td>varies<\/td>Active contention; latency will be unpredictable<\/td><\/tr>
>25%<\/td>varies<\/td>Not a shared-core product you can run a database on<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Steal is reported by the hypervisor, so it is trustworthy when it is high and uninformative when it is zero \u2014 some hypervisors simply do not expose it. Cross-check with \/proc\/stat<\/code> on the guest: if the sum of user<\/code> + system<\/code> + idle<\/code> does not add up to wall-clock time × vCPUs, the missing time is stolen regardless of what st<\/code> says.<\/p>\n\n\n\n
Axis 2: Single-Core Speed Is Usually the Binding Constraint<\/h2>\n\n\n\n
Most VPS workloads \u2014 PHP-FPM workers, MySQL query execution, Node.js event loops, Redis command processing \u2014 are single-threaded per request. Four slow cores beat two fast cores only when you have real concurrency; below roughly 50 requests per second, single-core speed dominates response time.<\/p>\n\n\n\n
sudo sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run | grep 'events per second'\nsysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run | grep 'events per second'<\/code><\/pre>\n\n\n\n
Events\/sec (1 thread, prime 20000)<\/th>CPU class<\/th>Typical price band<\/th><\/tr><\/thead>
2,000\u20132,400<\/td>Older Xeon E5 \/ EPYC 7002, often oversubscribed<\/td>Entry, $5\u20138<\/td><\/tr>
2,600\u20133,200<\/td>Xeon Scalable Gold, EPYC 7003<\/td>Mid, $10\u201325<\/td><\/tr>
3,400\u20134,200<\/td>Recent EPYC 9004 \/ 9005, Ryzen dedicated<\/td>Upper mid, $25\u201350<\/td><\/tr>
4,500+<\/td>Dedicated Ryzen \/ current-gen with high clock<\/td>$50+<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Absolute numbers drift with sysbench version, so compare candidates using the same binary and the same prime count. A 40% gap between two “same price” plans on this test is a 40% gap in your application’s response time at low concurrency \u2014 a difference no amount of nginx tuning can recover.<\/p>\n\n\n\n
Axis 3: Disk Is Not “Size” \u2014 It Is IOPS Tier and Backing Store<\/h2>\n\n\n\n
Ask three questions in this order. First, is the storage local to the hypervisor or is it a network block device? Local NVMe gives sub-0.2 ms p99 at queue depth 1; network-attached storage is typically 0.5\u20132 ms and far more variable. Second, is there a published IOPS cap and does it scale with disk size? Third \u2014 and most important \u2014 what does the p99 look like after ten minutes of sustained writes, when any burst credit has been spent?<\/p>\n\n\n\n
sudo fio --name=rw --ioengine=libaio --direct=1 --bs=4k --iodepth=32 \\\n  --rw=randwrite --size=2G --runtime=600 --time_based \\\n  --write_iops_log=\/tmp\/fio --log_avg_msec=10000 --group_reporting\n\n# Read the per-10s IOPS from the log to see burst credit expire\nawk -F, '{print $2, $8}' \/tmp\/fio_iops.1.log | sort -k2 -n | head -5<\/code><\/pre>\n\n\n\n
A disk that reports 20,000 IOPS in the first ten seconds and 1,200 IOPS from minute three onward is sold on burst credit. That is not a defect \u2014 it is a product \u2014 but it means your database write path will behave completely differently during a bulk import than during normal traffic. Test with the workload you will actually run, and test it for at least ten minutes.<\/p>\n\n\n\n
Axis 4: Does the Guest Span One NUMA Node?<\/h2>\n\n\n\n
Within a guest you rarely see the physical topology, but you can infer it. If lscpu<\/code> reports two sockets or two NUMA nodes on a 2-vCPU instance, the guest has been split across a boundary. Memory-bound workloads then pay remote-node latency on every access.<\/p>\n\n\n\n
lscpu | grep -E 'Socket|Core|Thread|NUMA node'\nnumactl --hardware 2>\/dev\/null | head -8\n# Compare local vs remote memory bandwidth\nnumactl --cpunodebind=0 --membind=0 sysbench memory --memory-block-size=1M \\\n  --memory-total-size=4G --threads=1 run | grep 'transferred'\nnumactl --cpunodebind=0 --membind=1 sysbench memory --memory-block-size=1M \\\n  --memory-total-size=4G --threads=1 run | grep 'transferred'<\/code><\/pre>\n\n\n\n
A 15% or larger drop on the remote-node run means memory bandwidth is node-local and your workload is placed badly. You cannot fix this from inside the guest; it is a placement decision made by the provider. It is also a legitimate reason to ask for the instance to be re-scheduled, if the provider supports it.<\/p>\n\n\n\n
Axis 5: Network Path, Not Just Port Speed<\/h2>\n\n\n\n
Two providers in the same city can differ by 30 ms of RTT to your users if one has a direct peer with their ISP and the other backhauls traffic to a transit exchange in another country. Measure from the VPS to the actual eyeball networks your users are on, not to a generic “speed test” node.<\/p>\n\n\n\n
for t in 1.1.1.1 8.8.8.8 9.9.9.9; do\n  echo \"== $t\"; mtr -rwzc 100 -i 0.2 $t | tail -1\ndone\n# Number of distinct ASes on the path to your users\nmtr -rwzc 50 -z  | awk '{print $(NF-1)}' | uniq | wc -l<\/code><\/pre>\n\n\n\n
Turning Axes Into a Purchase Decision<\/h2>\n\n\n\n
Score each candidate on the axes that matter for the workload, not on a single composite number. A rule that works for most small production stacks:<\/p>\n\n\n\n