Guide VPS & Servers

How to check whether your server is performing

Measuring your own server with sysbench, dd and iperf3, and why comparing today against last month matters more than any single number.

iFastHosting Support Team Updated 26 August 2026 9 min read Intermediate

"Is this server actually slow, or does it just feel slow?" is a question you can answer with real numbers rather than a guess, using a handful of standard tools. The value of running these yourself is not a single absolute figure — it is having a baseline on your own server that you can measure again later and compare against, which is what actually tells you whether something has changed.

Compare a server against itself, not against a number from elsewhere

Benchmark results depend heavily on the specific hardware, current load from other processes, storage type, and configuration at the moment you run them. A figure quoted somewhere else for "a VPS" is not a meaningful comparison for yours. Run these tools once now, save the output, and run them again after a change — a software update, a config tweak, a resize — to see what actually moved.

CPU: sysbench

sudo apt install sysbench -y      # Ubuntu / Debian
sudo dnf install sysbench -y      # RHEL / Rocky / AlmaLinux

Run a CPU test calculating prime numbers up to a fixed limit, using all available cores:

sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

$(nproc) automatically fills in the number of CPU cores available, so the test uses your server's full capacity. The output reports events per second and total execution time — save it, and run the identical command again after any change you want to evaluate.

Disk: dd and sysbench fileio

A quick, rough write-speed check:

dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct
rm testfile

oflag=direct bypasses the operating system's page cache, so you are measuring the disk itself rather than how fast data can be written into memory. Without it, a small enough test file can complete almost instantly regardless of true disk speed, which is a common and misleading mistake when running this test.

For a more thorough test that separates read and write performance and simulates realistic access patterns, sysbench's fileio mode is more representative than a single dd run:

sysbench fileio --file-total-size=2G prepare
sysbench fileio --file-total-size=2G --file-test-mode=rndrw --time=60 run
sysbench fileio --file-total-size=2G cleanup

The middle command is the actual test; the first prepares the test files and the last removes them afterwards — do not skip the cleanup step, or the test files are left consuming disk space.

Network: iperf3

Testing network throughput needs a second machine to test against, since it measures the connection between two points rather than one server in isolation. Install iperf3 on both:

sudo apt install iperf3 -y      # Ubuntu / Debian
sudo dnf install iperf3 -y      # RHEL / Rocky / AlmaLinux

On one machine, start a server:

iperf3 -s

From the other, connect and run the test:

iperf3 -c server-ip-address

The result reports throughput between the two specific points tested — useful for comparing your own connection over time, or between two of your own servers, but not a general statement about "the network" independent of where the other endpoint actually is.

Web server response time under load

If the actual concern is how your website performs, testing the web server directly under simulated concurrent load is more relevant than a raw CPU or disk number. Apache Bench, which ships alongside the Apache tools package, is a simple option:

sudo apt install apache2-utils -y      # provides ab, works against any web server
ab -n 200 -c 10 http://yourdomain.com/

-n is the total number of requests, -c is how many run concurrently. This reports requests per second and response time distribution for your own site as it is currently configured — a genuinely useful before-and-after comparison when testing a caching change or a configuration tweak.

Do not load-test a site you do not own, and go easy on your own

Running a load test against a domain generates real traffic that a receiving server has to handle — only ever point these tools at your own infrastructure, and start with modest numbers on a production server rather than immediately simulating heavy concurrent load against something people are actively using.

Making sense of what you find

If numbers look poor compared to your own server's history, check first whether something else is currently consuming resources — see seeing what is using your server resources before assuming the hardware itself is the problem. A busy background process, a runaway job, or memory pressure pushing the system into swap can all make a server appear to perform worse than its actual capacity, and none of those are fixed by moving to bigger hardware.

If measured performance genuinely and consistently falls short of what a workload needs even with nothing else running, that is a sizing question rather than a configuration one — see how much RAM does my VPS need? and VPS or dedicated server: where the line is, and talk to us about what a different tier would actually change for your specific workload.