Performance & reliability

Steal time is the percentage of time your virtual CPU was ready to run but the hypervisor gave the physical core to someone else. It appears as the "st" column in top. Anything consistently above 2–3% means you are competing for the core, and it is the usual cause of unexplained latency spikes on a shared-vCPU instance.

In order of likelihood: memory exhaustion causing swap thrashing, disk IO saturation, CPU steal time on shared cores, an unoptimised database, or network latency to your users. Check free -h and the st column in top first — between them they identify the cause about eighty per cent of the time.

Within a metro, under 5 ms. Within a continent, 10–40 ms. Across the Atlantic, 70–90 ms. Europe to Asia, 150–200 ms. Antipodal routes, 250–320 ms. Light in fibre travels at roughly two-thirds of c and real paths are about 1.35 times the great-circle distance, so about 1 ms per 100 km each way is the floor.

A well-configured 2 vCPU / 4 GB instance serves a static site to millions of monthly visits, a cached WordPress site to roughly 300,000, and an uncached dynamic application to perhaps 30,000. The variable that dominates is caching, not hardware — the same instance differs by two orders of magnitude depending on it.

Measure the three things that actually vary: single-thread CPU with sysbench, disk with fio at 4K random read/write, and network with iperf3 to a known endpoint. Run each several times across different hours — a single benchmark measures that minute, not the server.

Roughly five times the random IOPS — about 500,000 versus 90,000 — and around five times lower latency, under 0.1 ms versus about 0.5 ms. Sequential throughput is six to ten times higher. For database-backed applications the random-IOPS gap is the one you actually feel.

Our SLA is 99.99% per instance, which permits about 4.4 minutes of downtime a month, and observed availability across the fleet over the last twelve months was 99.993%. Anything beyond that requires redundancy you build yourself — a single machine, however good, is a single point of failure.

Indirectly and measurably. Search engines do not rank by server country, but they do measure page speed, and distance is latency. A server 200 ms from your users costs real Core Web Vitals score. Use a CDN if your audience is global; place the origin near your audience if it is regional.

DDoS protection filters attack traffic upstream of your server so legitimate requests still arrive. It has to be always-on to be useful — mitigation that activates after an attack starts has already let you go down. OnionVPS includes up to 12 Tbps of L3/L4 scrubbing at every tier, including the $4 plan.

The isolation is strong: KVM enforces separation in hardware, and escaping it is a serious research-grade exploit. The realistic risk is not the hypervisor — it is your configuration. Password SSH, unpatched software and an open service you forgot about account for essentially all real-world compromises.

A shared vCPU is scheduled against other tenants, so under contention your process waits — visible as steal time. A dedicated vCPU is a physical thread reserved for you with nothing else scheduled on it. Shared is fine for idle-most-of-the-time work; dedicated is necessary for anything with a latency requirement.