Speed and sizing
Choosing between two server quotes usually comes down to guessing — "4 vCPU / 8 GB" is what you are sold, not what you actually get. SixPreflight's benchmarks answer the question a review cannot: on this exact machine, with this exact data, how fast is it really.
Four benchmarks, one button each
Pick the first one if you only run one.
| Benchmark | What it tells you | Takes |
|---|---|---|
| Measure my real data | Times the queries this platform actually runs, against your own tables, and names the screen you feel each one on. Read-only — the same selects your admin panel and apps already run, nothing written. Report totals that read the whole order history by design are judged on time alone, not marked wasteful — a SUM over every order reads every order, and that is the job. | about 10 seconds |
| Test the processor | Pure CPU and memory, no database, no application file — safe to run on a live shop. Scored so 100 is an ordinary current-generation cloud processor, 200 is twice as fast. The same work runs three times, so a server that is only fast in bursts cannot hide it. | about 6 seconds |
| Test the database | Creates one table of its own, writes rows into it, reads them back every way a shop does, then drops it. Your application tables are never touched. | about 7 seconds |
| Test how much traffic it can take | Fires real requests at the shop at rising concurrency and reports the requests per second it sustains before responses start queueing. Let it pick the ceiling from your processor count, or set it yourself — 10, 100, up to 500 simultaneous requests. | one to two minutes |
What "traffic" actually means
The traffic test's number is simultaneous requests, and it is worth being precise about that, because "how many users can my server take" is usually asked with a different number in mind.
A signed-up user costs the server nothing while they are not doing anything. Even an active shopper — scrolling, reading, choosing — sends a request only every few seconds. So a shop sustaining 50 requests per second is comfortably serving roughly 250 to 500 people actively using the app at that moment, and far more registered customers than that. The tool prints this conversion next to its result, so the number you quote to yourself is the honest one.
Run it on a quiet hour: it is real load, deliberately, and while it runs the shop is genuinely busy.
Reading the scores
Both scores are normalised so they mean the same thing at any difficulty setting — only the machine changes them, and higher is always faster. A current cloud vCPU reads about 100. Run the processor test two or three times at different hours of the day — a burstable instance drops sharply once its included credits run out, and a single run will not show that.
On the database score, watch single-row insert throughput in particular. With durable commit settings turned on, each insert waits for a real disk sync, so that number is really measuring your storage's write latency — which is the clearest difference between one hosting provider and another.
Is it safe to run on a live shop?
Yes, on both counts, and it is worth knowing exactly why rather than just taking that on trust.
The real-data benchmark is read-only by construction, not by convention.
Every query it runs goes through one code path that refuses to issue anything except a read. There is no route in that code that can reach an INSERT, UPDATE, DELETE or DROP.
The database session itself is put into a read-only transaction mode wherever the server supports it, so even a mistake would be rejected by the database rather than by this code.
Every query also carries a hard time limit, so a probe against an unexpectedly large table cannot sit holding resources on a live site. A probe that hits the limit is reported as "too slow" — which is itself a useful finding.
The database benchmark creates and drops one table of its own, named with a random suffix so it can never collide with anything real. It checks the name is free before creating anything, and aborts without touching anything if a table by that name somehow already exists. Cleanup runs even if the request is interrupted or the page times out, so the table cannot be left behind by an unlucky moment.
Comparing two servers before you rent one
Everything else in SixPreflight answers "is this server ready". The comparison tool answers the other question: given two or three quotes, which one is actually faster, and is the gap something money fixes or something a config file fixes.
- Run the processor and database benchmarks on each candidate server.
- Copy that server's result — one line of text, with no IP address, hostname or domain in it, so it is safe to paste into a chat or a support ticket.
- Paste the other results into any one of the servers. You get a ranking, a plain sentence saying which to buy, and how many concurrent requests each machine can seat.
Do not rank servers by the scan grade
Speed and configuration are kept on separate axes on purpose. Speed is what costs money to change; the grade measures tuning, which is free — you raise the buffer pool, switch OPcache on, and the grade moves. Rank by grade instead of by the benchmark and you will reliably end up buying the slower machine with a straight face.
Apply the recommended database settings from The "What to fix" page first, then compare — otherwise you are comparing two different configurations, not two machines.
For a server that has nothing installed on it yet, a standalone command-line version of the same benchmark exists with no application and no dependencies, so you can measure a candidate VPS before deciding whether to put anything on it at all.
Where to go next
- Which PHP, database and OS version — the full measured comparison behind the recommended stack
- Reading the report — how the grade and the benchmark score relate to each other