| Latency and packet loss<\/td> | Routing quality and peering<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe 20-Minute Test Suite<\/h2>\n\n\n\nInstall the tools and run each test twice \u2014 once right after provisioning and once a few hours later, ideally during peak hours in the provider’s timezone:<\/p>\n\n\n\n apt install -y sysbench fio iperf3\nsysbench cpu run --threads=1 --time=30\nsysbench cpu run --threads=$(nproc) --time=30\nfio --name=randread --rw=randread --bs=4k --size=1G --iodepth=32 --runtime=30 --time_based\nfio --name=seqwrite --rw=write --bs=64k --size=1G --runtime=30 --time_based\niperf3 -c -t 30\nping -c 20 <\/code><\/pre>\n\n\n\nWatch CPU Steal, Not Just Core Count<\/h2>\n\n\n\nA “4-core” plan on an oversold host can perform worse than a 2-core plan on a quiet one. The number that exposes this is CPU steal \u2014 the percentage of time the hypervisor gives your vCPU to other tenants. Run top<\/code> and look at the %st<\/code> column while you repeat the sysbench test:<\/p>\n\n\n\ntop -bn1 | grep '%Cpu'\n# st (steal) should stay under 2-3% during the benchmark<\/code><\/pre>\n\n\n\nRe-run the single-threaded sysbench test five times over the day. If the events-per-second figure swings by more than 20%, the host is contended and your production traffic will feel it at peak hours. This is exactly why the cheap plans that look identical on paper benchmark so differently in practice.<\/p>\n\n\n\n Network: Test to Your Users, Not to the Provider<\/h2>\n\n\n\nSpeed tests against the provider’s own servers are meaningless \u2014 everything inside their network is fast. Point iperf3 at a server in the region your visitors actually come from, and use mtr<\/code> to check the route:<\/p>\n\n\n\nmtr -rwbc 20 \niperf3 -c -t 30 -R<\/code><\/pre>\n\n\n\nHigh latency or packet loss at an intermediate hop (not the last one) points to cheap transit or poor peering. If your users are in the US and the test server is in Europe, expect the geography to show up in the numbers \u2014 test to the region that matters for your<\/em> site, not for the provider’s marketing page.<\/p>\n\n\n\nRead the Fine Print on I\/O Bursts<\/h2>\n\n\n\nMany budget providers advertise disk speed based on burst capability: the plan can hit 500 MB\/s for a few seconds, then drops to a sustained limit of 20 MB\/s. Your fio test above measures the sustained number only if you run it long enough. Extend the random-read test to 60 seconds and watch the throughput curve \u2014 if it starts high and collapses, you are on a burst-limited disk:<\/p>\n\n\n\n fio --name=burst --rw=randread --bs=4k --size=2G --iodepth=32 --runtime=60 --time_based --output-format=json | python3 -c \"import json,sys; d=json.load(sys.stdin); print('avg IOPS:', d['jobs'][0]['read']['iops_mean'])\"<\/code><\/pre>\n\n\n\nFor a database or any write-heavy workload, the sustained number is the one that keeps your site alive at 6 PM, not the burst number from the marketing page. If the provider does not publish sustained I\/O limits, the 60-second fio run is your answer.<\/p>\n\n\n\n
|