A key diagnostic indicator of CPU contention on VPS is CPU steal time<\/strong> (visible in
\/proc\/stat<\/code>, top<\/code>, vmstat<\/code>), reflecting CPU time taken by the hypervisor in favor of other guests.
This article proposes a reproducible benchmark protocol (fio\/sysbench\/iperf3\/pgbench) with \u226510 repeated 60-second runs<\/strong> plus long runs (1\u20136 hours, recommended 4h)<\/strong> with telemetry (iostat\/vmstat\/sar\/pidstat).
The Results section provides a demonstration dataset and charts<\/strong> that are explicitly marked as simulated<\/strong>, constructed to reflect published patterns of variability in shared environments (tail events, interference, and diagnostic value of %steal<\/code>).
We show how to compare p95\/p99 statistically via bootstrap confidence intervals for differences of medians<\/strong> and the Mann\u2013Whitney U test<\/strong>, and how to report effect sizes (Cliff\u2019s delta \/ probabilistic dominance).
Practical implication: for IO-bound systems (databases, logs, persistent queues), disk tail latency predominates; for CPU-bound workloads, %steal<\/code> is critical; for network-bound services, jitter\/p99 RTT plus port throughput are decisive. <\/p>\n\n\n\nIntroduction<\/h2>\n\n\n\n
In infrastructure hosting, comparing VPS and Dedicated is more rigorous when framed as a comparison of resource-sharing models<\/strong> and their resulting latency distributions<\/strong>, rather than a direct comparison of \u201ccores and gigabytes.\u201d
In large and distributed services, rare latency spikes and tail latency<\/strong> events can disproportionately affect user experience; eliminating variability sources completely\u2014especially in shared environments\u2014is usually impractical.
Multi-tenancy can cause performance interference: a \u201cnoisy neighbor\u201d may degrade other tenants\u2019 metrics, and shared storage\/network subsystems can show noticeable variability even when average throughput looks acceptable.
Therefore, reproducible comparisons should publish not only throughput\/IOPS but also p50\/p95\/p99 latency<\/strong>, plus system contention signals such as %steal<\/strong> and %iowait<\/strong>, and time dynamics<\/strong> in long runs. <\/p>\n\n\n\nProblem, hypotheses, and assumptions<\/h2>\n\n\n\nProblem statement<\/h3>\n\n\n\n
Goal: define a reproducible protocol that allows a hosting provider (or customer) to compare VPS and Dedicated service classes under representative configurations and workloads, then interpret results in terms of tail latency, variability, and root causes (CPU scheduling, I\/O contention, network behavior). <\/p>\n\n\n\n
Research questions<\/h3>\n\n\n\n\n- RQ1: Do VPS and Dedicated differ in p95\/p99 disk latency for database\/log-relevant profiles (fsync-write)?\u00a0<\/li>\n\n\n\n
- RQ2: How different is network variability (RTT\/jitter) and throughput (iperf3) between VPS and Dedicated?\u00a0<\/li>\n\n\n\n
- RQ3: Do %steal and %iowait explain observed tail-latency spikes and degradations?\u00a0<\/li>\n<\/ul>\n\n\n\n
Operational hypotheses<\/h3>\n\n\n\n
H1: Dedicated shows a lower median p99 latency for synchronous writes (fsync) and lower temporal spread of p99 than shared VPS.
H2: VPS exhibits non-zero %steal correlated with increased p99 latency (host-level CPU contention as a tail-latency factor).
H3: A premium VPS with guaranteed resources approaches Dedicated in tail latency and %steal but may still lag under shared storage\/network contention. <\/p>\n\n\n\n
Representative benchmark configurations<\/h3>\n\n\n\n
When providers\/tariffs are unspecified, we evaluate these representative classes (treated as classes of setups<\/em>, not vendor products): <\/p>\n\n\n\n\n- small VPS<\/strong>: 1 vCPU, 2 GB RAM, SSD (shared CPU)<\/li>\n\n\n\n
- medium VPS<\/strong>: 2 vCPU, 4 GB RAM, NVMe (shared CPU)<\/li>\n\n\n\n
- premium VPS<\/strong>: 4 vCPU, 8 GB RAM, NVMe + \u201cguaranteed resources\u201d (assumption: reduced oversubscription\/CPU pinning and disk QoS)<\/li>\n\n\n\n
- dedicated small<\/strong>: 4 cores, 16 GB RAM, 1\u00d7NVMe, 1G<\/li>\n\n\n\n
- dedicated large<\/strong>: 8 cores, 32 GB RAM, 2\u00d7NVMe, 10G\u00a0<\/li>\n<\/ul>\n\n\n\n
Explicit assumptions (fixed for reproducibility)<\/h3>\n\n\n\n\n- OS\/kernel:\u00a0Ubuntu Server 24.04 LTS<\/strong>,\u00a0Linux kernel 6.8.x<\/strong>.\u00a0<\/li>\n\n\n\n
- CPU governor:\u00a0
performance<\/code>\u00a0(reduce DVFS-related variance during tests).\u00a0<\/li>\n\n\n\n- I\/O scheduler:\n
\n- NVMe<\/strong>:\u00a0
none<\/code><\/li>\n\n\n\n- SATA\/SAS SSD<\/strong>\u00a0(small VPS \u201cSSD\u201d class):\u00a0
mq-deadline<\/code>\u00a0<\/li>\n<\/ul>\n<\/li>\n\n\n\n- Filesystem\/mount:\u00a0
ext4<\/code>\u00a0with\u00a0noatime,nodiratime<\/code>.\u00a0<\/li>\n\n\n\n- VPS oversubscription is unknown and not measured directly;\u00a0%steal<\/strong>\u00a0is used as a proxy for host-level CPU contention.\u00a0<\/li>\n\n\n\n
- VPS storage model assumed as a shared pool; hence heavier latency tails are expected than on single-tenant local NVMe.\u00a0<\/li>\n<\/ul>\n\n\n\n
Materials and methods<\/h2>\n\n\n\nWhat exactly is compared<\/h3>\n\n\n\n
This study interprets \u201cVPS vs Dedicated\u201d as a comparison of two deployment architectures: <\/p>\n\n\n\n
\n- VPS as a guest OS under a hypervisor (typical stack: KVM + paravirtualized virtio devices).<\/li>\n\n\n\n
- Dedicated as an OS running directly on physical hardware.\u00a0<\/li>\n<\/ol>\n\n\n\n
Tools and outputs<\/h3>\n\n\n\n\n- fio<\/strong>: IOPS\/BW and completion latency percentiles (clat), exported in JSON for aggregation.\u00a0<\/li>\n\n\n\n
- sysbench<\/strong>: modular benchmark for CPU and memory.\u00a0<\/li>\n\n\n\n
- iperf3<\/strong>: throughput (JSON output with\u00a0
-J<\/code>).\u00a0<\/li>\n\n\n\n- pgbench<\/strong>: database-class benchmark (TPS and transaction latency statistics).\u00a0<\/li>\n\n\n\n
- sysstat<\/strong>\u00a0stack (sar\/iostat\/pidstat): telemetry and per-process attribution.\u00a0<\/li>\n<\/ul>\n\n\n\n
Mandatory contention metrics:<\/p>\n\n\n\n
\n- %steal<\/strong>\u00a0(CPU time desired by the guest but not granted due to host scheduling).\u00a0<\/li>\n\n\n\n
- %iowait<\/strong>\u00a0(CPU idle while waiting for I\/O completion).\u00a0<\/li>\n<\/ul>\n\n\n\n
Benchmark profiles and exact parameters<\/h3>\n\n\n\nfio profiles (storage)<\/h4>\n\n\n\n
We use these fixed fio profiles (block size, queue depth, and sync semantics are explicit): <\/p>\n\n\n\n
\nrandread<\/code>: 4k,\u00a0iodepth=32<\/code><\/li>\n\n\n\nrandwrite<\/code>: 4k,\u00a0iodepth=32<\/code><\/li>\n\n\n\nrandwrite + fsync<\/code>: 4k,\u00a0iodepth=1<\/code>,\u00a0direct=1<\/code>,\u00a0fsync=1<\/code>\u00a0<\/li>\n<\/ul>\n\n\n\nPercentiles are reported as p50\/p95\/p99 of completion latency (clat). <\/p>\n\n\n\n
sysbench profiles (CPU\/memory)<\/h4>\n\n\n\n\nsysbench cpu<\/code><\/li>\n\n\n\nsysbench memory<\/code>\u00a0<\/li>\n<\/ul>\n\n\n\nNetwork profiles<\/h4>\n\n\n\n\niperf3 -t 60 -J<\/code><\/li>\n\n\n\nping -i 0.2 -c 300<\/code>\u00a0and compute p50\/p95\/p99 RTT from raw output.\u00a0<\/li>\n<\/ul>\n\n\n\nExperimental design and telemetry<\/h3>\n\n\n\n\n- Short runs:\u00a060 seconds<\/strong>,\u00a0\u226510 repeats<\/strong>\u00a0per test and configuration.\u00a0<\/li>\n\n\n\n
- Long runs:\u00a01\u20136 hours<\/strong>, recommended\u00a04 hours<\/strong>, tracking time series of p99 and system metrics.\u00a0<\/li>\n\n\n\n
- Optional warm-up exclusion: first 5\u201310 seconds may be excluded (especially for TCP slow-start in iperf3).\u00a0<\/li>\n\n\n\n
- Telemetry capture cadence (example): 1-second iostat\/vmstat\/sar sampling into log files.\u00a0<\/li>\n<\/ul>\n\n\n\n
flowchart LR\n A[Provision VPS\/Dedicated host] --> B[Fix OS\/kernel and CPUFreq\/I-O scheduler settings]\n B --> C[Install tools: fio, sysbench, iperf3, pgbench, sysstat]\n C --> D[Short runs: 60s \u00d7 10 repeats (disk\/network\/CPU)]\n C --> E[Long run: 1\u20136 hours (recommended 4h) with p99 time series]\n D --> F[Collect telemetry: iostat\/vmstat\/sar\/pidstat and %steal]\n E --> F\n F --> G[Parse JSON\/logs into unified CSV]\n G --> H[Compute p50\/p95\/p99 + statistical analysis]\n H --> I[Publish tables + CDFs + time-series figures]<\/code>\n\n![\"\"](\"https:\/\/hosting.international\/blog\/wp-content\/uploads\/2026\/02\/test-res-scaled.png\")
\n<\/pre>\n\n\n\nResults<\/h2>\n\n\n\nImportant note on data provenance<\/h3>\n\n\n\n
Live measurements are not possible in this environment<\/strong>, so the results below are simulated<\/strong> as a publication-ready example<\/em> of how to report and analyze VPS vs Dedicated. The simulation is constructed to reflect published qualitative patterns: heavier tails and \u201crare spikes\u201d in shared environments, storage\/network interference, and the diagnostic role of %steal. <\/p>\n\n\n\nSimulation model (explicit).<\/strong> To generate plausible tails and spikes:<\/p>\n\n\n\n\n- Per-run latencies are drawn from a heavy-tailed distribution (e.g., lognormal or mixture-of-lognormals) calibrated to target percentiles.<\/li>\n\n\n\n
- Long-run p99 time series are produced by a baseline process plus rare spikes (e.g., a Poisson shock process) to emulate intermittent contention, with spike probability\/scale higher for shared VPS classes than for Dedicated.<\/li>\n\n\n\n
- %steal is generated as a correlated variable that increases in spike windows to reflect host-level contention coupling.\u00a0<\/li>\n<\/ul>\n\n\n\n
Disk results (fio) \u2014 simulated, medians across 10 runs<\/h3>\n\n\n\n
Table 1. fio profiles (simulated; medians across 10 runs). lat p50\/p95\/p99<\/code> are completion latency (clat) percentiles. <\/p>\n\n\n\nWorkload (fio)<\/th> Configuration<\/th> IOPS (median)<\/th> BW (MiB\/s, median)<\/th> lat p50 (ms)<\/th> lat p95 (ms)<\/th> lat p99 (ms)<\/th> CPU steal (%, median)<\/th> CPU iowait (%, median)<\/th><\/tr><\/thead> randread 4k, iodepth=32<\/td> vps_small<\/td> 17,800<\/td> 69.5<\/td> 0.352<\/td> 1.630<\/td> 3.821<\/td> 3.884<\/td> \u2014<\/td><\/tr> randread 4k, iodepth=32<\/td> vps_medium<\/td> 64,234<\/td> 250.9<\/td> 0.203<\/td> 0.963<\/td> 2.217<\/td> 1.876<\/td> \u2014<\/td><\/tr> randread 4k, iodepth=32<\/td> vps_premium<\/td> 90,128<\/td> 352.1<\/td> 0.151<\/td> 0.631<\/td> 1.311<\/td> 0.623<\/td> \u2014<\/td><\/tr> randread 4k, iodepth=32<\/td> ded_small<\/td> 156,443<\/td> 611.1<\/td> 0.121<\/td> 0.465<\/td> 0.879<\/td> 0.043<\/td> \u2014<\/td><\/tr> randread 4k, iodepth=32<\/td> ded_large<\/td> 261,811<\/td> 1022.7<\/td> 0.100<\/td> 0.412<\/td> 0.781<\/td> 0.024<\/td> \u2014<\/td><\/tr> randwrite 4k, iodepth=32<\/td> vps_small<\/td> 12,606<\/td> 49.2<\/td> 0.457<\/td> 2.233<\/td> 5.703<\/td> 3.463<\/td> \u2014<\/td><\/tr> randwrite 4k, iodepth=32<\/td> vps_medium<\/td> 45,396<\/td> 177.3<\/td> 0.283<\/td> 1.318<\/td> 3.091<\/td> 1.837<\/td> \u2014<\/td><\/tr> randwrite 4k, iodepth=32<\/td> vps_premium<\/td> 71,426<\/td> 279.0<\/td> 0.202<\/td> 0.850<\/td> 1.763<\/td> 0.648<\/td> \u2014<\/td><\/tr> randwrite 4k, iodepth=32<\/td> ded_small<\/td> 120,956<\/td> 472.5<\/td> 0.161<\/td> 0.622<\/td> 1.188<\/td> 0.048<\/td> \u2014<\/td><\/tr> randwrite 4k, iodepth=32<\/td> ded_large<\/td> 201,886<\/td> 788.6<\/td> 0.141<\/td> 0.569<\/td> 1.087<\/td> 0.033<\/td> \u2014<\/td><\/tr> randwrite 4k + fsync, iodepth=1<\/td> vps_small<\/td> 556<\/td> 2.2<\/td> 2.048<\/td> 18.373<\/td> 60.267<\/td> 3.673<\/td> 11.339<\/td><\/tr> randwrite 4k + fsync, iodepth=1<\/td> vps_medium<\/td> 880<\/td> 3.4<\/td> 1.021<\/td> 9.378<\/td> 34.889<\/td> 1.746<\/td> 7.361<\/td><\/tr> randwrite 4k + fsync, iodepth=1<\/td> vps_premium<\/td> 1,438<\/td> 5.6<\/td> 0.606<\/td> 3.255<\/td> 9.046<\/td> 0.705<\/td> 3.135<\/td><\/tr> randwrite 4k + fsync, iodepth=1<\/td> ded_small<\/td> 2,225<\/td> 8.7<\/td> 0.402<\/td> 1.538<\/td> 2.865<\/td> 0.053<\/td> 1.552<\/td><\/tr> randwrite 4k + fsync, iodepth=1<\/td> ded_large<\/td> 2,605<\/td> 10.2<\/td> 0.351<\/td> 1.224<\/td> 2.145<\/td> 0.025<\/td> 1.047<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nInterpretation: the fsync profile<\/strong> (bottom five rows) is the most revealing for shared environments, because synchronous writes expose tail latency due to queueing, background activity, and shared contention\u2014consistent with the \u201crare spikes\u201d thesis for service quality. <\/p>\n\n\n\nFigure 1 (simulated): CDF of disk latency (fsync write).<\/p>\n\n\n\n
Figure 2 (simulated): 4-hour time series of p99 fsync-write latency.<\/p>\n\n\n\n
Network results \u2014 simulated, medians across 10 runs<\/h3>\n\n\n\n
Table 2. RTT and iperf3 metrics (simulated; medians across 10 runs). Ping percentiles p50\/p95\/p99 are used to capture jitter and tail RTT, and iperf3 JSON output supports programmatic aggregation. <\/p>\n\n\n\nMetric<\/th> vps_small<\/th> vps_medium<\/th> vps_premium<\/th> ded_small<\/th> ded_large<\/th><\/tr><\/thead> ping RTT p50 (ms)<\/td> 0.904<\/td> 0.804<\/td> 0.703<\/td> 0.601<\/td> 0.551<\/td><\/tr> ping RTT p95 (ms)<\/td> 2.651<\/td> 2.084<\/td> 1.543<\/td> 1.222<\/td> 1.010<\/td><\/tr> ping RTT p99 (ms)<\/td> 5.043<\/td> 3.516<\/td> 2.323<\/td> 1.718<\/td> 1.339<\/td><\/tr> iperf3 TCP throughput (Gbps, median)<\/td> 0.860<\/td> 0.962<\/td> 1.264<\/td> 0.903<\/td> 9.113<\/td><\/tr> iperf3 TCP retransmits (median, per 60s)<\/td> 161<\/td> 119<\/td> 76<\/td> 60<\/td> 27<\/td><\/tr> CPU steal during network test (%, median)<\/td> 3.227<\/td> 2.139<\/td> 0.662<\/td> 0.052<\/td> 0.036<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nPractical interpretation: in multi-tenant infrastructure, it is insufficient to report bandwidth alone; p95\/p99 RTT and jitter (tail behavior) matter because they affect \u201cchattiness\u201d of distributed services (many short RPCs\/requests). <\/p>\n\n\n\n
Figure 3 (simulated): CDF of ping RTT.<\/p>\n\n\n\n
Statistical analysis<\/h2>\n\n\n\nMetrics and formulas<\/h3>\n\n\n\n
Latency percentiles.<\/strong> For an observed latency sample ( {x_1,\\dots,x_n} ), the (p)-th percentile (Q_p) is the value such that approximately (p%) of observations are (\\le Q_p). In practice, percentiles are computed by a defined quantile estimator (report which implementation is used). <\/p>\n\n\n\nIOPS and bandwidth relationship.<\/strong> For fixed block size (b) (bytes), the relationship is:
[ \\text{BW} \\approx \\text{IOPS} \\times b ] or equivalently
[ \\text{IOPS} \\approx \\frac{\\text{BW}}{b} ] When BW is reported in MiB\/s and (b) in bytes, unit conversion is required. <\/p>\n\n\n\nHypothesis testing methodology (bootstrapping + nonparametric test)<\/h3>\n\n\n\n
The protocol uses: <\/p>\n\n\n\n
\n- Percentile bootstrap<\/strong>\u00a0for the difference of medians (e.g., ( \\Delta = \\text{median}(p99)_A – \\text{median}(p99)_B )).\n
\n- Resample each group with replacement (B) times (e.g., (B=10{,}000)), compute (\\Delta^{(b)}).<\/li>\n\n\n\n
- The 95% confidence interval is ([\\Delta_{2.5%}, \\Delta_{97.5%}]).\u00a0<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Mann\u2013Whitney U test<\/strong>\u00a0(two-sample rank test) as a nonparametric test of distributional shift (\u201ctends to be larger\u201d). Report: p-value and a probabilistic dominance interpretation (MW parameter).\u00a0<\/li>\n\n\n\n
- Effect size<\/strong>:\u00a0Cliff\u2019s delta<\/strong>\u00a0(dominance). A convenient interpretation is:
[ \\delta = P(X>Y) – P(X<Y) ] where (X) comes from group A and (Y) from group B.\u00a0<\/li>\n<\/ol>\n\n\n\nExample statistical results (simulated)<\/h3>\n\n\n\n
Table 3. Comparison using 10 independent runs (simulated). Reported: \u0394 median, bootstrap CI, bootstrap p-value, Mann\u2013Whitney p-value, MW probabilistic dominance ( \\varphi ), and Cliff\u2019s delta ( \\delta ). <\/p>\n\n\n\nComparison<\/th> Metric<\/th> median(A)<\/th> median(B)<\/th> \u0394 median(A\u2212B)<\/th> 95% bootstrap CI for \u0394<\/th> p_bootstrap<\/th> p_MW<\/th> MW \u03d5<\/th> Cliff\u2019s \u03b4<\/th><\/tr><\/thead> vps_medium vs ded_small<\/td> fsync lat p99 (ms)<\/td> 34.889<\/td> 2.865<\/td> 32.025<\/td> [31.073; 32.558]<\/td> 4.00e-05<\/td> 1.83e-04<\/td> 1.000<\/td> 1.000<\/td><\/tr> vps_premium vs ded_small<\/td> fsync lat p99 (ms)<\/td> 9.046<\/td> 2.865<\/td> 6.181<\/td> [6.070; 6.934]<\/td> 4.00e-05<\/td> 1.83e-04<\/td> 1.000<\/td> 1.000<\/td><\/tr> vps_medium vs ded_small<\/td> RTT p99 (ms)<\/td> 3.516<\/td> 1.718<\/td> 1.798<\/td> [1.746; 1.843]<\/td> 4.00e-05<\/td> 1.83e-04<\/td> 1.000<\/td> 1.000<\/td><\/tr> vps_medium vs vps_premium<\/td> CPU steal (%, fsync)<\/td> 1.746<\/td> 0.705<\/td> 1.041<\/td> [0.751; 1.540]<\/td> 4.00e-05<\/td> 1.83e-04<\/td> 1.000<\/td> 1.000<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nInterpretation of MW \u03d5 and Cliff\u2019s \u03b4: both are dominance-style measures; values close to 1 indicate strong separation where group A tends to produce higher values than group B (here: higher latency or higher steal). <\/p>\n\n\n\n
Discussion and threats to validity<\/h2>\n\n\n\nWhy tail latency matters more than averages<\/h3>\n\n\n\n
For many online services, \u201crare\u201d slow events become a material fraction of user-visible requests at scale (tail-at-scale effect). Variability sources\u2014queues, background activity, shared-resource contention\u2014are difficult to eliminate entirely. <\/p>\n\n\n\n
Why I\/O often breaks predictability first<\/h3>\n\n\n\n
In multi-tenant infrastructure, shared storage and shared services are prone to interference and higher variability. Databases are particularly sensitive to disk behavior: interference and contention translate into application-level response-time variance and SLA degradation. <\/p>\n\n\n\n
%steal as a VPS differentiator<\/h3>\n\n\n\n
Steal time is CPU time needed by the guest but not provided by the host because resources were allocated elsewhere; it is observable in \/proc\/stat<\/code> and standard monitoring tools.
Operationally: if tail latency and %steal rise together while guest CPU load appears \u201cnormal,\u201d the bottleneck is likely host-level CPU contention (typical under oversubscription). This is a concrete engineering input for choosing between shared VPS, \u201cguaranteed\u201d VPS, and Dedicated. <\/p>\n\n\n\nLimitations and threats to validity<\/h3>\n\n\n\n
Simulated results vs live measurements.<\/strong> The Results values are not tied to any specific data center; they demonstrate reporting structure and typical effects from the literature (tail variability, multi-tenant interference, and %steal diagnostic value). <\/p>\n\n\n\nInstrumentation validity.<\/strong> fio percentile computation depends on internal accounting and can vary with logging\/aggregation mode; therefore, live studies should fix fio version, output format (JSON), and preserve raw artifacts. <\/p>\n\n\n\nConstruct validity (synthetic vs production).<\/strong> fio\/sysbench\/iperf3\/pgbench capture important aspects but do not replace profiling of real applications; they remain useful as \u201cminimal reproducible\u201d tests for comparing infrastructure classes. <\/p>\n\n\n\nExternal validity (transferability).<\/strong> Results from one region\/storage class\/network may not transfer to others; multi-tenant background noise varies over time, so tests should be repeated in different time windows and reported via distributions\/percentiles rather than single numbers. <\/p>\n\n\n\nPractical recommendations, decision checklist, conclusion, and appendix<\/h2>\n\n\n\nPractical recommendations (SLO\/risk language)<\/h3>\n\n\n\n\n- If the target service is\u00a0IO-bound<\/strong>\u00a0(databases, logs, queues with fsync, heavy writes), the key KPI is\u00a0p99 latency<\/strong>\u00a0under\u00a0
randwrite+fsync<\/code>. For stable p99 requirements, Dedicated or premium VPS with explicit CPU\/I\/O guarantees is often justified.\u00a0<\/li>\n\n\n\n- If the service is\u00a0CPU-bound<\/strong>\u00a0(rendering, compilation, pure compute, high-QPS processing), diagnose\u00a0%steal<\/strong>: persistent steal indicates shared-host CPU contention and supports choosing a guaranteed profile or Dedicated.\u00a0<\/li>\n\n\n\n
- If the service is\u00a0network-bound<\/strong>\u00a0(proxy\/edge, highly \u201cchatty\u201d microservices), publish p95\/p99 RTT and jitter plus iperf3 throughput\/retransmits because network tail latency degrades distributed-system behavior.\u00a0<\/li>\n<\/ul>\n\n\n\n
Decision checklist (engineering questions to ask)<\/h3>\n\n\n\n\n- CPU:<\/strong>\u00a0oversubscription constraints\/guarantees, CPU pinning\/\u201cguaranteed vCPU,\u201d typical %steal for the SLA class.\u00a0<\/li>\n\n\n\n
- Storage:<\/strong>\u00a0local NVMe vs shared pool, QoS for IOPS\/latency, availability of latency metrics\/graphs.\u00a0<\/li>\n\n\n\n
- Network:<\/strong>\u00a0port speed (1G\/10G), rate-limit\/PPS policy, expected p95\/p99 RTT intra-region, isolation guarantees.\u00a0<\/li>\n\n\n\n
- Observability:<\/strong>\u00a0permission to run sysstat tooling and collect iostat\/sar\/pidstat; constraints on benchmarking.\u00a0<\/li>\n<\/ol>\n\n\n\n
Conclusion<\/h3>\n\n\n\n
A journal-style VPS vs Dedicated publication should be centered on latency distributions and their sources<\/strong>: tail latency (p95\/p99) and temporal variability are more informative than averages, while multi-tenant interference and CPU contention can be diagnosed via system metrics such as %steal.
The proposed protocol (repeats + long runs + telemetry + bootstrap\/Mann\u2013Whitney analysis) enables reproducible and comparable reporting across tariff classes without tying conclusions to specific providers. <\/p>\n\n\n\nAppendix: reproducibility pack (bash) and table templates with filled examples<\/h3>\n\n\n\n
Below is a minimal bash command set to reproduce the protocol on any Linux host; parameters are explicit. Percentile interpretation follows fio documentation and standard \u201cX% of operations complete within \u2264 value\u201d semantics. <\/p>\n\n\n\n
Environment preparation<\/h4>\n\n\n\nbash# OS: Ubuntu\/Debian (example)<\/em>\nsudo apt-get update\nsudo apt-get install -y fio sysbench iperf3 postgresql-contrib sysstat procps\n\n# Record OS and tool versions for the protocol<\/em>\nuname -a\nlsb_release -a || cat \/etc\/os-release\nfio --version\nsysbench --version\niperf3 --version\npgbench --version\n\n# CPU governor<\/em>\nfor c in \/sys\/devices\/system\/cpu\/cpu*\/cpufreq\/scaling_governor; do\n echo performance | sudo tee \"$c\"\ndone\n\n# I\/O scheduler: inspect and (if needed) set<\/em>\nlsblk -d -o NAME,ROTA,TYPE,SIZE,MODEL\ncat \/sys\/block\/nvme0n1\/queue\/scheduler 2>\/dev\/null || true\necho none | sudo tee \/sys\/block\/nvme0n1\/queue\/scheduler 2>\/dev\/null || true\n<\/code><\/code><\/pre>\n\n\n\nfio short runs (60s \u00d7 10 repeats)<\/h4>\n\n\n\nbash\nTARGET_DIR=\/mnt\/bench\nmkdir -p \"$TARGET_DIR\"\n\n# 1) randread 4k, iodepth=32<\/em>\nfio --name=randread4k \\\n --directory=\"$TARGET_DIR\" --filename=fiofile \\\n --rw=randread --bs=4k --iodepth=32 --numjobs=1 \\\n --direct=1 --size=4G --runtime=60 --time_based \\\n --group_reporting --output-format=json \\\n > fio_randread4k.json\n\n# 2) randwrite 4k, iodepth=32<\/em>\nfio --name=randwrite4k \\\n --directory=\"$TARGET_DIR\" --filename=fiofile \\\n --rw=randwrite --bs=4k --iodepth=32 --numjobs=1 \\\n --direct=1 --size=4G --runtime=60 --time_based \\\n --group_reporting --output-format=json \\\n > fio_randwrite4k.json\n\n# 3) randwrite 4k + fsync, iodepth=1<\/em>\nfio --name=fsyncwrite4k \\\n --directory=\"$TARGET_DIR\" --filename=fiofile \\\n --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 \\\n --direct=1 --fsync=1 --size=2G --runtime=60 --time_based \\\n --group_reporting --output-format=json \\\n > fio_fsyncwrite4k.json\n<\/code><\/code><\/pre>\n\n\n\nLong run (recommended 4h) + telemetry<\/h4>\n\n\n\nbash\n# 1-second telemetry (example)<\/em>\niostat -x 1 > iostat_1s.log &\nIOSTAT_PID=$!\nvmstat 1 > vmstat_1s.log &\nVMSTAT_PID=$!\nsar -u -r -d 1 > sar_1s.log &\nSAR_PID=$!\n\n# 4 hours = 14400 seconds<\/em>\nfio --name=fsyncwrite4k_long \\\n --directory=\"$TARGET_DIR\" --filename=fiofile \\\n --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 \\\n --direct=1 --fsync=1 --size=2G --runtime=14400 --time_based \\\n --group_reporting --output-format=json \\\n > fio_fsyncwrite4k_4h.json\n\nkill $IOSTAT_PID $VMSTAT_PID $SAR_PID\n<\/code><\/code><\/pre>\n\n\n\nNetwork (iperf3 + ping)<\/h4>\n\n\n\nbash\n# On server:<\/em>\niperf3 -s\n\n# On client:<\/em>\niperf3 -c <SERVER_IP> -t 60 -J > iperf3_tcp_60s.json\nping -i 0.2 -c 300 <TARGET_IP> > ping_300.log\n<\/code><\/code><\/pre>\n\n\n\npgbench (optional, database-class signal)<\/h4>\n\n\n\nbash\ncreatedb pgbench\npgbench -i -s 10 pgbench\n\npgbench -c 10 -j 4 -T 60 -P 10 -l pgbench > pgbench_run1.log\npgbench -c 10 -j 4 -T 60 -r pgbench > pgbench_run1_percmd.log\n<\/code><\/code><\/pre>\n\n\n\nTable templates (filled example structure, not empty)<\/h4>\n\n\n\n
Table A1. Host specification report (example layout with the representative configurations used in this paper). <\/p>\n\n\n\nParameter<\/th> small VPS<\/th> medium VPS<\/th> premium VPS<\/th> dedicated small<\/th> dedicated large<\/th><\/tr><\/thead> CPU<\/td> 1 vCPU (shared)<\/td> 2 vCPU (shared)<\/td> 4 vCPU (guaranteed)<\/td> 4 cores<\/td> 8 cores<\/td><\/tr> RAM<\/td> 2 GB<\/td> 4 GB<\/td> 8 GB<\/td> 16 GB<\/td> 32 GB<\/td><\/tr> Storage<\/td> SSD (SATA class)<\/td> NVMe<\/td> NVMe + QoS<\/td> 1\u00d7NVMe<\/td> 2\u00d7NVMe<\/td><\/tr> Network<\/td> 1G class<\/td> 1G class<\/td> 1G class<\/td> 1G<\/td> 10G<\/td><\/tr> OS\/kernel<\/td> Ubuntu 24.04 \/ 6.8.x<\/td> same<\/td> same<\/td> same<\/td> same<\/td><\/tr> Governor<\/td> performance<\/td> performance<\/td> performance<\/td> performance<\/td> performance<\/td><\/tr> I\/O scheduler<\/td> mq-deadline<\/td> none<\/td> none<\/td> none<\/td> none<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTable A2. fio reporting template (example populated with the fsync p99 line from Results). <\/p>\n\n\n\nProfile<\/th> Configuration<\/th> IOPS<\/th> BW (MiB\/s)<\/th> clat p50 (ms)<\/th> clat p95 (ms)<\/th> clat p99 (ms)<\/th> %steal<\/th> %iowait<\/th><\/tr><\/thead> randwrite 4k + fsync qd1<\/td> vps_medium<\/td> 880<\/td> 3.4<\/td> 1.021<\/td> 9.378<\/td> 34.889<\/td> 1.746<\/td> 7.361<\/td><\/tr> randwrite 4k + fsync qd1<\/td> ded_small<\/td> 2,225<\/td> 8.7<\/td> 0.402<\/td> 1.538<\/td> 2.865<\/td> 0.053<\/td> 1.552<\/td><\/tr><\/tbody><\/table><\/figure>\n","protected":false},"excerpt":{"rendered":"Executive summary VPS and Dedicated differ less in \u201caverage speed\u201d than in latency predictability (p95\/p99) and resilience to multi-tenant interference (\u201cnoisy neighbor\u201d), which tends to be most visible in storage I\/O and networking. A key diagnostic indicator of CPU contention on VPS is CPU steal time (visible in \/proc\/stat, top, vmstat), reflecting CPU time taken by the hypervisor in favor of other guests. This […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[171],"tags":[175,177,174,176,172],"class_list":["post-701","post","type-post","status-publish","format-standard","hentry","category-lab-tests","tag-dedicated-server-performance","tag-hosting-lab-tests","tag-storage-i-o-performance","tag-vps-performance","tag-vps-vs-dedicated"],"_links":{"self":[{"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/posts\/701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/comments?post=701"}],"version-history":[{"count":1,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/posts\/701\/revisions"}],"predecessor-version":[{"id":703,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/posts\/701\/revisions\/703"}],"wp:attachment":[{"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/media?parent=701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/categories?post=701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hosting.international\/blog\/wp-json\/wp\/v2\/tags?post=701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}