Methodology
Formula version: 2026.07b
This page describes exactly what the code does: which tools run, how many times, and the formula that turns the results into a score. Nothing is hidden — you can re-check the numbers yourself.
The principle
A plan says “2 vCPU, 4 GB, NVMe”. That describes the invoice, not the performance. Two servers with the same plan line can differ several-fold — because of CPU generation, packing density, noisy neighbours and network quality.
So we do not compare promises. We run identical code on every server and publish the result together with its context: plan, location, date.
How a test runs
-
01
Order
A test is queued: provider, plan, location. The server is either rented by us or provided for measurement.
-
02
Preflight
The agent connects over SSH and checks the server is usable: free space, permissions, network access.
-
03
Bootstrap
Identical measurement tools are installed. apt, dnf, yum, apk, pacman and zypper are supported — the OS flavour does not matter.
-
04
Measure
Modules run in order: system → CPU → memory → disk → network. Key tests are repeated.
-
05
Parse
Raw tool output is parsed into metrics with units. The raw log is kept and available on the test page.
-
06
Score
Metrics are normalized and folded into 0–100 scores using the formula below. Rankings recompute automatically.
What we measure with
Standard open-source tools — deliberately, so that anyone can repeat the measurement and check our numbers.
| Tool | What it measures | Units | Passes |
|---|---|---|---|
| sysbench | CPU: single-threaded and multi-threaded | events/s | 3 passes → median |
| openssl speed | AES-256-GCM encryption | MB/s | 3 passes → median |
| gzip -6 | Data compression | MB/s | 3 passes → median |
| fio | Disk: 4K random read/write, 1M sequential read/write | IOPS and MB/s, p95/p99 latency | 1 pass per profile |
| ping | Latency to control endpoints (Cloudflare, Google, Quad9) | ms | packet series → median |
| curl | Download throughput | Mbit/s | 1 pass |
Memory is measured with two passes each for read and write. If a tool is unavailable, the agent marks that honestly in the result and uses a fallback (for example dd instead of fio — in which case IOPS are simply not published rather than invented).
Repeats and spread
CPU tests run three times, and the median is used — not the best result. At the same time we compute the spread across passes and publish it.
Spread is the most underrated number in benchmarking. If three consecutive passes produced noticeably different numbers, that indicates instability: the server shares resources with noisy neighbours. A steady 100 is usually better than bouncing between 80 and 140.
The overall score formula
The overall score is a weighted sum of five category scores. The weights reflect a typical VPS workload, where the network matters no less than the hardware.
| Category | Weight | Why |
|---|---|---|
| Ping | 23% | Latency to control endpoints — the first thing a user feels. |
| Speed | 23% | Download throughput of the link. |
| CPU | 22% | Compute, encryption, compression. |
| Disk | 22% | Random operations and sequential bandwidth. |
| Memory | 10% | RAM bandwidth. Less often the bottleneck, hence the lower weight. |
- sysbench, single thread 40%
- sysbench, all threads 35%
- OpenSSL AES-256-GCM 15%
- gzip 10%
- 4K random read (IOPS) 30%
- 4K random write (IOPS) 30%
- 1M sequential read 20%
- 1M sequential write 20%
Random operations carry twice the weight of sequential ones: real databases and web applications hit the disk that way, while the pretty “up to 5 GB/s” marketing numbers are sequential reads, which are rare in real life.
Normalization: from metric to score
IOPS cannot be compared to megabits directly, so every metric is mapped onto a 0–100 scale. We use a blend of two approaches:
- Relative (percentile). The result’s position between the 10th and 90th percentile of a comparable group. Robust to outliers: one anomalous server cannot break the scale.
- Absolute (log scale). The result’s position inside a reference “poor → excellent” range (table below). Independent of who else we happened to test.
With a sample of 5 or more comparable results, the score is 0.5 × percentile + 0.5 × absolute scale. With fewer results — the absolute scale only.
Why blend: on pure percentiles the slowest server in a small group scored 0 out of 100 even with perfectly decent numbers. That is misinformation. The absolute component stops a score collapsing to zero when a server is objectively fine, and as data accumulates the score converges towards the relative one.
| Metric | Reference range (0 → 100) | Units |
|---|---|---|
| CPU, single thread | 120 – 6,000 | events/s |
| CPU, all threads | 200 – 60,000 | events/s |
| AES-256-GCM | 200 – 12,000 | MB/s |
| gzip | 20 – 400 | MB/s |
| Memory | 3,000 – 60,000 | MiB/s |
| 4K random read | 1,500 – 250,000 | IOPS |
| 4K random write | 1,000 – 200,000 | IOPS |
| 1M sequential read | 150 – 8,000 | MB/s |
| 1M sequential write | 100 – 5,000 | MB/s |
| Ping | 1 – 250 | ms (lower is better) |
| Download speed | 50 – 10,000 | Mbit/s |
The scale is logarithmic: the difference between 1,000 and 10,000 IOPS matters more in real workloads than between 200,000 and 210,000. For ping the scale is inverted — fewer milliseconds give a higher score.
Task-specific rankings
A “best server overall” is a meaningless notion: a game server needs ping, a database needs disk. So besides the overall ranking we compute separate ones with different weights:
| Use case | Weights |
|---|---|
| Database | Disk 40% · Memory 35% · CPU 25% |
| VPN | Ping 50% · Speed 50% |
| Game server | Ping 75% · Speed 25% |
| Streaming | Speed 60% · Ping 40% |
| Web hosting | CPU 30% · Disk 30% · Ping 20% · Speed 20% |
| Compute | CPU 70% · Memory 30% |
Fairness of the calculation
- The formula and its version are public. Changing weights means changing the version.
- Paid placements and affiliate links do not affect the calculation or positions. Advertising is labelled and kept outside the ranking.
- Provider-initiated tests are labelled but scored with the same formula.
- Manual position adjustments do not exist — there is nowhere in the code to put them.
What this methodology cannot do
An honest method must state its limits. Ours:
- It is a snapshot, not a guarantee. A result belongs to a specific server at a specific moment. Tomorrow a noisy neighbour may appear on that node.
- One server does not describe a whole provider. The more tests a provider has across locations, the more reliable the conclusion. We always show the test count.
- We do not measure support, multi-year uptime or billing. Those matter, but an agent cannot measure them in 20 minutes.
- Network speed depends on the route. A measurement from Europe to Asia describes the link between those points, not a “bad” server.
- A provider could in theory detect a test and hand out better resources. Regular, unannounced re-measurements are the counterweight.
Check our work
Every test page exposes the raw log — the tools’ output before any processing. The tools are standard and the parameters are described above: anyone can run the same thing on their own server and compare.
Found an error in a measurement or a calculation — write to us: the contact form. Confirmed errors are corrected publicly.
See also: About the project · Terms of Use