See how an AccuWeb.Cloud VM performs under controlled testing across web load, CPU, memory, storage, and network performance — using documented open-source benchmark tools you can reproduce yourself. See how an AccuWeb.Cloud VM performs under controlled benchmark testing. We tested CPU, memory, storage, web throughput and private networking using the same methodology used for our New York region. See how an AccuWeb.Cloud VPS performs under controlled testing across web load, CPU, memory, storage, and network performance — using documented open-source tools you can reproduce yourself. See how an AccuWeb.Cloud VM performs under controlled testing across web load, CPU, memory, storage, and network performance — using documented open-source benchmark tools you can reproduce yourself.
AccuWeb.Cloud's performance report measures real cloud hosting performance on a standard 4 vCPU / 8 GB Cloud VPS — not just theoretical specifications. Using k6, sysbench, fio, and iperf3, we benchmark web load, CPU scaling, memory bandwidth, disk I/O, and private network latency across tested regions, including New York, with median results reported across five controlled runs. It is designed for teams comparing cloud hosting providers, evaluating Cloud VPS performance for production workloads, or validating how advertised infrastructure performs under real concurrent load. Our Los Angeles benchmark uses a standard 4 vCPU / 8 GB cloud VM, a separate load-generator VM and documented open-source tools. CPU, memory and key storage tests were repeated across controlled runs, while the web-load test used the same k6 workload profile adopted for New York. AccuWeb.Cloud's performance report measures real cloud hosting performance on a standard 4 vCPU / 8 GB Cloud VPS — not just theoretical specifications. Using k6, sysbench, fio, and iperf3, we benchmark web load, CPU scaling, memory bandwidth, disk I/O, and private network latency across repeated, controlled runs. It is designed for teams comparing cloud hosting providers, evaluating Cloud VPS performance for production workloads, or validating how advertised infrastructure performs under load. AccuWeb.Cloud's performance report measures real cloud hosting throughput on a standard 4 vCPU / 8 GB Cloud VPS — not a spec sheet. Using k6, sysbench, fio and iperf3, we benchmark web load, CPU scaling, memory bandwidth, disk I/O and private network latency in each region, with median results reported for the repeated CPU, memory and key 4K storage tests. It's built for teams comparing cloud hosting providers, evaluating cloud VPS performance for a production workload, or checking whether a host's advertised specs hold up under real concurrent load.
We publish the VM configuration, testing tools, run count, and measured results — including where performance begins to degrade under stress — so you can evaluate the results yourself or reproduce the same tests against another provider. The page focuses on measured behavior instead of theoretical hardware claims. Results are tied to the VM size, benchmark tool and test conditions used. We publish the VM configuration, testing tools, run count, and measured results — including where performance begins to degrade under stress — so you can evaluate the numbers yourself or reproduce the same tests anywhere. Most hosting providers quote theoretical maximums pulled from a spec sheet. We publish the VM configuration, the tools, the run count and the raw results so you can judge it yourself, or reproduce it against any other provider.
9,640 req/sec at 1,000 concurrent users, 7.09ms P95, 0% errors. 9,334 req/sec at 1,000 concurrent users with 20.60 ms P95. 9,531 req/sec at 1,000 concurrent users, 11.16 ms P95. 9,380 req/sec at 1,000 concurrent users, 19.63ms P95, 0% errors.
Near-linear ~3.97× throughput scaling from 1 to 4 vCPU. Single-vCPU and full 4-vCPU CPU throughput with 4.00x scaling. Near-linear 4.00x throughput scaling from 1 to 4 vCPU. Near-linear ~4.00× throughput scaling from 1 to 4 vCPU.
~30.3 GiB/s read, ~20.8 GiB/s write throughput. Sequential read and write memory throughput using sysbench. 8.4 GiB/s read, 5.7 GiB/s write. ~13.3 GiB/s read, ~11.3 GiB/s write throughput.
13.1K random read IOPS at ~0.42ms P95 latency. Sequential bandwidth and 4K random read/write IOPS. 27,400 random read IOPS at 0.196 ms P95 latency. 9,296 random read IOPS at ~0.52ms P95 latency.
0.26ms private VM-to-VM latency, 0% packet loss. Private VM-to-VM latency, packet loss and throughput. 0.593 ms private VM-to-VM latency, 0% packet loss. ~0.82ms private VM-to-VM latency, 0% packet loss.
Equinix Tier-3 data centers behind every one of these numbers. Dedicated benchmark VMs with isolated workload generation. Equinix Tier-3 data centers behind every one of these numbers. Enterprise-grade cloud infrastructure behind every one of these numbers.
Third-party names and marks belong to their respective owners and are shown for identification only.
Pricing comparison based on equivalent configurations as of 1 August 2026.
Every result below comes from a live test on a standard Cloud VPS instance, giving you a quick view of web, storage, memory, and network performance. Quick reference values from the Los Angeles benchmark. Every result below comes from a live test on a standard Cloud VPS instance, giving you a quick view of web, storage, memory, and network performance. Every result below comes from a live test on a standard Cloud VPS instance in the Frankfurt region — bookmark this table if you're evaluating providers on more than price.
| Benchmark | Measured result | What it means |
|---|---|---|
| Web performance | 9,640 req/sec 9,334 req/sec 9,531 req/sec 9,380 req/sec | Handles thousands of HTTP requests every second Throughput at 1,000 concurrent virtual users Handles thousands of HTTP requests every second HTTP requests handled every second at 1,000 concurrent users |
| P95 response time | 7.09 ms 20.60 ms 11.16 ms 19.63 ms | 95% of requests completed within about 7 ms 95% of requests completed within about 21 ms 95% of requests completed within about 11 ms 95% of requests completed within about 20 ms |
| HTTP success rate | 100% | No failed requests during the selected load test 0% HTTP errors observed at the selected load point No failed requests during the selected load test No failed requests during the selected load test |
| 4K random read | 13.1K IOPS 9,822 IOPS 27,400 IOPS 9,296 IOPS | Fast response for application and small-file workloads Small-block random storage performance Fast response for application and small-file workloads Random read performance for application and small-file workloads |
| Memory read | 30.3 GiB/s ~13.1 GiB/s ~8.4 GiB/s ~13.3 GiB/s | High-speed memory throughput Median sequential memory-read throughput High-speed memory throughput Memory read throughput |
| Disk read Sequential disk read | 390 MiB/s 443 MiB/s 688 MiB/s 463 MiB/s | Strong sequential storage performance Direct-I/O sequential read performance Strong sequential storage performance Sequential storage read throughput |
| Private network latency | 0.26 ms 0.501 ms 0.593 ms ~0.82 ms | Fast VM-to-VM communication within the tested region Average VM-to-VM latency in the test Fast VM-to-VM communication within the same region VM-to-VM communication latency within the region |
We gradually increased concurrent virtual users while monitoring throughput, response time and HTTP failures.
This is the same load profile most WordPress, Laravel and Node.js sites see during a traffic spike. See how it stacks up on our price & feature comparison page.
A static Nginx page was tested with k6 using the NY-matched workload: http.get + sleep(0.1), 30 seconds per stage.
We gradually increased concurrent virtual users while monitoring throughput, response time and HTTP failures. A static Nginx page was tested with k6 using the NY-matched workload: http.get + sleep(0.1), 30 seconds per stage. See how it stacks up on our price & feature comparison.
We gradually increased concurrent virtual users while monitoring throughput, response time and HTTP failures. A static Nginx page was tested with k6 using the NY-matched workload: http.get + sleep(0.1), 30 seconds per stage.
| Concurrent users | Req/sec | P95 | Errors |
|---|---|---|---|
| 100 | 986 981.52 982.23 978.71 | 2.03 ms 2.35 ms 2.74 ms 3.32 ms | 0% |
| 250 | 2,462 2,449.73 2,453.36 2,448.75 | 1.76 ms 2.63 ms 2.22 ms 2.43 ms | 0% |
| 500 | 4,907 4,850.29 4,900.13 4,849.44 | 2.98 ms 5.44 ms 2.20 ms 6.12 ms | 0% |
| 1,000 Sweet spot | 9,640 9,334.26 9,531.48 9,380.06 | 7.09 ms 20.60 ms 11.16 ms 19.63 ms | 0% |
Web results are based on a lightweight static Nginx HTTP workload and should not be interpreted as equivalent performance for every application. Web results represent a lightweight static Nginx workload and should not be interpreted as equivalent performance for every application. Web results are based on a lightweight static Nginx workload and should not be interpreted as equivalent performance for every application. Web results are based on a lightweight static Nginx HTTP workload and should not be interpreted as equivalent performance for every application.
Reading the table: P95 stayed between 2.20 and 2.74 ms up to 500 concurrent users and was 11.16 ms at 1,000, with 0% HTTP errors at every stage.
Need more headroom later? Vertical scaling adds vCPUs to an existing VM, while auto horizontal scaling adds whole new instances under sustained load. sysbench CPU testing used cpu-max-prime=20000 for 30 seconds across five controlled runs. Need more headroom later? Vertical scaling adds vCPUs to an existing VM, while auto horizontal scaling adds whole new instances under sustained load. sysbench used cpu-max-prime=20000 for 30 seconds per run. Need more headroom later? Vertical scaling adds vCPUs to an existing VM, while auto horizontal scaling adds whole new instances under sustained load.
| CPU test | Result |
|---|---|
| Single vCPU | ~1,710 events/sec 592.73 events/sec 514.10 events/sec 594.61 events/sec |
| 4 vCPU | ~6,793 events/sec 2,368.92 events/sec 2,057.81 events/sec 2,376.57 events/sec |
| CPU scaling | ~3.97× 4.00x 4.00x ~4.00× |
Moving from one vCPU to four vCPUs delivered almost 4× the processing throughput in our test. Additional compute resources translate efficiently into additional processing capability. Moving from one benchmark thread to four produced about 4x the measured CPU event rate in this test. Moving from one benchmark thread to four produced about 4x the measured CPU event rate in this test. Additional compute resources translate efficiently into additional processing capability. Moving from 1 to 4 vCPU produced about 4× the measured CPU event rate in this test, on the AMD EPYC Rome CPU platform.
Memory bandwidth matters most for in-memory caches (Redis), database buffer pools, and anything running under fully managed hosting where we tune these settings for you. Sequential sysbench memory tests used a 256 MB block and 30-second runs. Memory bandwidth matters most for in-memory caches (Redis), database buffer pools, and anything running under fully managed hosting where we tune these settings for you. Sequential sysbench memory tests used a 256 MB block and 30-second runs. Memory bandwidth matters most for in-memory caches (Redis), database buffer pools, and other memory-intensive workloads.
| Memory test | Result |
|---|---|
| Read | ~30.3 GiB/s ~13.1 GiB/s ~8.4 GiB/s ~13.3 GiB/s |
| Write | ~20.8 GiB/s ~10.1 GiB/s ~5.7 GiB/s ~11.3 GiB/s |
Memory tests were repeated multiple times using a working set large enough to reduce CPU-cache influence. Raw medians: 13,420.08 MiB/s read and 10,350.11 MiB/s write. Raw medians: 8,584.51 MiB/s read and 5,871.48 MiB/s write. Raw medians: 13,607.56 MiB/s read and 11,594.83 MiB/s write.
5 controlled runs · Median result shownRandom I/O speed is what separates a snappy database from a slow one. Every VM ships with automated backup storage on top of this performance, at no extra setup cost. fio used temporary files only with direct I/O; no raw devices were tested. Random I/O speed is what separates a snappy database from a slow one. fio used temporary files only with direct I/O; no raw devices were tested. Random I/O speed is what separates a snappy database from a slow one. Platform backup options — including a complimentary 7-day disaster recovery backup and optional Backup Storage — are available alongside this performance.
| Test | Result |
|---|---|
| Sequential read | ~390 MiB/s 443 MiB/s 688 MiB/s 463 MiB/s |
| Sequential write | ~261 MiB/s 247 MiB/s 421 MiB/s 87.5 MiB/s |
| Test | Result | P95 |
|---|---|---|
| 4K random read Random read 4K random read 4K random read | ~13.1K IOPS 9,822 27,400 IOPS 9,296 IOPS | ~0.42 ms 0.474 ms 0.196 ms ~0.52 ms |
| 4K random write Random write 4K random write 4K random write | ~2.84K IOPS 2,506 7,451 IOPS 898 IOPS | ~0.45 ms 0.396 ms 0.155 ms ~1.27 ms |
These measurements help represent workloads involving databases, applications, operating-system activity and large-file transfers.
5 controlled runs · Median result shown 4K tests: 5 controlled runs · Median result shownSub-millisecond VM-to-VM latency matters for multi-tier apps — an API server talking to a database, or app nodes behind a load balancer. See our full list of global data centers for region-to-region options. Private VM-to-VM testing measured latency and throughput between the dedicated target and load-generator VMs. Sub-millisecond VM-to-VM latency matters for multi-tier apps — an API server talking to a database, or app nodes behind a load balancer. See our full list of global data centers for region-to-region options. Sub-millisecond VM-to-VM latency matters for multi-tier apps — an API server talking to a database, or app nodes behind a load balancer. See our full list of global data centers for region-to-region options.
| Network test | Result |
|---|---|
| Private VM-to-VM latency | ~0.26 ms 0.501 ms 0.593 ms ~0.82 ms |
| Packet loss | 0% |
| Configured VM bandwidth | 200 Mbps |
| Measured throughput Measured receiver throughput Measured receiver throughput | ~191 Mbps |
| Direction | Symmetric |
Measured ~191 Mbps in both directions against the configured 200 Mbps limit, alongside very low VM-to-VM latency in the same test. Measured ~191 Mbps against the configured 200 Mbps limit, alongside very low VM-to-VM latency in the same test. Measured ~191 Mbps against the configured 200 Mbps limit, alongside very low VM-to-VM latency in the same test. Ping min / avg / max: 0.680 / 0.821 / 0.991 ms.
These benchmarks run on the same infrastructure every AccuWeb.Cloud customer gets — dedicated resources on Equinix Tier-3 data centers, backed by a team that's run this platform at scale for years. The Los Angeles benchmark was run only on dedicated test VMs, with the load generator kept separate from the target so traffic generation did not consume resources on the VM being measured. The Mumbai benchmark was run only on dedicated test VMs, with the load generator kept separate from the target so traffic generation did not consume resources on the VM being measured. These benchmarks run on AccuWeb.Cloud's production cloud infrastructure in Frankfurt, using dedicated resources and backed by a team with years of experience operating cloud platforms at scale.
See the Security & Compliance Report →A 4 vCPU / 8 GB / 100 GB Cloud VPS on Ubuntu 24.04 LTS and AMD EPYC Milan hardware, plus a separate load-generator VM. Target and load-generator VMs were separate and matched at 4 vCPU / 8 GB / 100 GB. A 4 vCPU / 8 GB / 100 GB VM on Ubuntu 24.04.5 LTS and Intel Xeon Cascadelake hardware, plus a separate matched load-generator VM. A 4 vCPU / 8 GB / 100 GB Cloud VPS on Ubuntu 24.04 LTS and AMD EPYC Rome CPU platform, plus a separate load-generator VM.
k6 for web load, sysbench for CPU and memory, fio for storage, iperf3 for network — five runs each. k6, sysbench, fio, iperf3 and mpstat were used for measurement. k6 for web load, sysbench for CPU and memory, fio for storage, iperf3 for network, mpstat for CPU monitoring. k6 for web load, sysbench for CPU and memory, fio for storage, iperf3 for network.
We publish the representative median result, including where performance degrades under stress. Web-load settings matched the New York methodology for regional comparison. We publish the representative median result, with web-load settings matched to the New York methodology. We publish representative median results for the repeated CPU, memory and key 4K storage tests.
| Region | New York Los Angeles Mumbai Frankfurt |
| Target VM | 4 vCPU / 8 GB RAM / 100 GB disk |
| Load generator | Separate 4 vCPU / 8 GB VM |
| Operating system | Ubuntu 24.04 LTS Ubuntu 24.04.5 LTS |
| CPU platform | AMD EPYC Milan AMD EPYC Rome @ 2.0 GHz Intel Xeon Cascadelake AMD EPYC Rome |
| Web server | Nginx Nginx 1.24.0 Nginx 1.24.0 Nginx |
| CPU / memory testing | sysbench sysbench 1.0.20 sysbench 1.0.20 sysbench |
| Storage testing | fio fio 3.36 fio 3.36 fio |
| Network testing | iperf3 iperf3 3.16 iperf3 3.16 iperf3 |
| Web load testing | k6 k6 v2.2.0 k6 v2.2.0 k6 |
The corrected web-load rerun used a new dedicated LA benchmark VM pair with the same required specification and NY-matched k6 workload.
Hardware note: Mumbai runs on Intel Xeon Cascadelake, while Los Angeles runs on AMD EPYC Rome. VM size and methodology are identical; the CPU generation difference is noted for transparency.
Hardware note: CPU platforms differ by region — New York runs AMD EPYC Milan, Los Angeles and Frankfurt run AMD EPYC Rome, and Mumbai runs Intel Xeon Cascadelake. VM size and benchmark tools are the same; the CPU generation difference is noted for transparency.
A separate load-generator VM was used so that traffic generation did not consume resources on the VM being measured.
CPU, memory and key storage benchmarks were repeated multiple times, with representative or median results used to reduce the effect of unusual individual runs.
| Term | Simple explanation |
|---|---|
| Requests/sec | Number of web requests processed every second How many web requests the server processed each second. |
| P95 latency | 95 out of every 100 requests completed within this time 95 out of every 100 requests completed within this response time. |
| IOPS | Number of small storage operations completed every second The number of small storage operations completed each second. |
| 4K random I/O | Small 4 KB disk reads/writes used to evaluate application and database storage Small 4 KB disk reads/writes commonly used to evaluate application and database storage. |
| MiB/s & GiB/s | Storage and memory data transferred per second, respectively |
| MiB/s | Storage data transferred per second. |
| GiB/s | Memory data transferred per second. |
| Concurrent users / VUs | Simulated users accessing the server at the same time Simulated users accessing the test server at the same time. |
| Packet loss | Network data that failed to reach its destination Network packets that failed to reach the destination. |
| CPU scaling | How efficiently performance increases when more vCPUs are available How effectively measured throughput increased when more vCPUs were used. |
| Median | The middle result from repeated tests, avoiding unusually high or low runs skewing the figure The middle result from repeated runs, reducing the influence of unusually high or low results. |
Please ask your queries. We are available 24/7
Choose the resources and region that fit your workload — the same infrastructure behind every number on this page.
