Benchmarks are easy to run and easy to misread. A number produced in ten seconds on an idle machine tells you very little about how that machine will serve your site, and comparing two providers on those numbers usually compares the wrong thing.
Decide what you are measuring first
Three different questions get answered with the word "benchmark".
Is this machine what I was sold? A quick capability check after provisioning.
Is it performing as it did? A comparison against your own earlier measurement.
Will it run my workload? The only question that usually matters, and the one synthetic tests answer worst.
Be clear which you are asking, because the right test differs for each. How to Plan Server Capacity and When to Scale goes into the third properly.
Check the hardware is what you ordered
Worth doing on day one, and it is not really a benchmark.
lscpu free -h lsblk
Processor model and core count, memory, and the disks present. On a dedicated server, confirm the disks are the type you paid for and that RAID is configured as agreed.
Discrepancies happen, and they are far easier to resolve in the first week than six months later. Provisioning and Initial Setup of a Dedicated Server explains the rest of that first day.
Synthetic tests, and what they miss
CPU benchmarks measure a workload that is not yours: usually pure computation with everything in cache. A web server spends most of its time waiting on the database and the disk.
Disk tests are more useful, and only if configured to resemble reality. A sequential read test measures something a database never does; databases perform many small random reads, and the two numbers differ by an order of magnitude on the same hardware.
Network tests measure the route to whichever server you tested against, at that moment. One result is not a measure of the provider's network.
Test the thing you actually run
The measurement that answers the useful question.
Put your real application on the machine and load-test it: concurrent requests against real pages, including the slow ones, with a realistic amount of data in the database.
What you are looking for is not requests per second in the abstract. It is the concurrency at which response times start climbing. That number is your capacity, and it is nowhere in a synthetic score.
For a shop, test checkout specifically. It cannot be cached, it touches everything, and it is where capacity actually binds. How to Prepare Your Store for a Sales Peak explains that case.
Run it more than once, and not just after a reboot
A single run on a freshly booted machine measures the best case: nothing cached, nothing competing, no accumulated state.
Run each test several times and take the spread in place of the best figure. On virtualised hosting the variance between runs is itself informative. A wide spread means you are sharing with neighbours whose activity you cannot see.
Test at different times of day for the same reason. A machine that benchmarks well at three in the morning and poorly at nine tells you something a single number cannot.
Do not benchmark a live server
A load test consumes the resources your visitors need, and a disk test can saturate storage shared with other customers.
On shared or virtualised hosting that will be noticed, and it may breach the terms you agreed to. Test before the server is in service, or on an identical machine that is not.
If you must measure something live, measure passively: response times from outside, and resource usage over time. For that, see Monitoring Performance and Server Health.
Keep the numbers
A benchmark is most useful compared with itself.
Record the results, the date, and what the machine was doing at the time. Then when someone says the server feels slower, there is a number to compare against in place of an impression.
That also catches gradual degradation; a failing disk, a noisy neighbour, a configuration change, which is invisible without a baseline. How to Manage Multiple Servers Consistently walks through keeping that record alongside the build notes.
Comparing providers honestly
If you are choosing between two, run the same test on both, at the same time of day, several times, with the same software versions.
Then weigh the result against what you learned that a benchmark cannot show: how quickly support answered a real question, what the renewal price is, and how easily you could leave. For that, see How to Choose a Hosting Provider.
A machine that benchmarks 10% higher and takes a day to answer a ticket is the worse purchase, and no test on this page will tell you that.
The first benchmark has a second purpose: proving the hardware is sound before it carries anything. How to Test a New Server Before Putting It into Service goes into that pass.
Fix what varies before measuring
A benchmark is a comparison, and it only compares what you intended if everything else is held still.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>/dev/null sensors 2>/dev/null | grep -iE 'core|temp' | head -4 uptime; who
A processor scaling its frequency by demand produces different results at the start and end of a run. A machine that is thermally limited produces a fast first minute and a slower tenth.
Run each test long enough to reach a steady state rather than measuring the burst. A figure taken in the first thirty seconds describes the best case, which is not the case the server operates in.
Measure the storage the way the application uses it
Sequential throughput is the figure providers quote and it is rarely the figure that matters.
dd if=/dev/zero of=/tmp/t bs=1M count=2048 oflag=direct 2>&1 | tail -1 fio --name=rand --rw=randread --bs=4k --size=512M --numjobs=4 --runtime=30 --group_reporting 2>/dev/null | grep -E 'IOPS|lat' rm -f /tmp/t
A database does small reads scattered across a large file, which is a completely different workload from writing one large file. A disk that looks excellent on the first test can be poor on the second.
Match the test to what the machine will actually do. Benchmarking sequential throughput for a server that will run a database tells you almost nothing useful about how it will feel.
A benchmark answers a question you should state first
Numbers without a question produce comparisons that cannot be acted on.
Useful questions sound like: is this machine faster than the one it replaces, does it handle the traffic we expect with room to spare, is the provider delivering what was described. Each implies a specific test and a specific comparison.
date; nproc; free -g | head -2 uname -r; cat /etc/os-release | head -2
Record the conditions alongside every result: the date, the kernel, the specification and what else was running. A number without those cannot be compared against anything later, which is what makes most stored benchmark results useless within a year.