Why your new server benchmarks slower than the old one when it isn't.
A lower bogomips reading after a migration isn't a slower server, it's a virtualisation artifact. What it really measures, and how to test real work.
In this article 5 sections
A common question after a migration is whether a lower bogomips reading means a slower server. It does not. Here is how we answered it.
- A customer who had just migrated onto our platform noticed that a value called bogomips read lower than on his old box, and asked whether the new server was slower.
- bogomips measures nothing you'd want to buy. It's a boot-time calibration loop the kernel runs to size its own internal delays. On a virtual host it reflects the guest's presented clock, while the physical core underneath still runs at full turbo.
- Do not take the proxy on trust. Run the real benchmarks yourself, cryptographic and CPU workloads, on both machines: a newer processor generation is faster, with wider instructions. The real work answers the question.
- The lesson: a measurement is only as good as what it measures. Don't argue the proxy. Name what it really measures, then let real work settle it.
The number behind the question
He had compared bogomips on his old machine and his new one, and the new reading came back lower. Read at face value, that looks like a downgrade. It isn't, and to see why you have to know what that number is.
$ grep -m1 bogomips /proc/cpuinfoWhat bogomips actually measures
bogomips is not a benchmark. It's a boot-time calibration loop the kernel runs once to size its own internal timing delays, so it knows roughly how many busy-loops fit in a given interval. The name is a joke the kernel developers made at their own expense: bogus millions of instructions per second. On a virtualised host the number is more bogus than usual, because it reflects the guest's presented clock, the value the hypervisor hands the VM, while the physical core underneath is still running at full turbo. A lower bogomips reading is a quirk of how virtualisation exposes the clock, not a loss of anything real.
“bogomips measures nothing you'd want to buy.”
The reading dropped. The silicon didn't.
The proxy metric vs the real work
Every 'my server got slower' argument is really a fight about what you chose to measure. Put the proxy next to the work and the fight ends.
| THE PROXY: BOGOMIPS | THE REAL WORK: A BENCHMARK | |
|---|---|---|
| What it actually is | A boot-time calibration loop the kernel runs once to size its own timing delays | Cryptographic and CPU workloads that stand in for what your app does under load |
| What it reads on a virtual host | The guest's presented clock, a number the hypervisor hands the VM | Instructions retired against the physical core, still running at full turbo |
| THE ONE THAT MATTERSDoes it move when the hardware gets newer? | Not reliably. It tracks a virtualised clock value, not the silicon | Yes. A newer generation with wider instructions does more per cycle |
| When it's measured | Once, at boot, then never again | On demand, as many times as you want, by you |
| Can you buy it? | No one sells bogomips, and no user ever felt one | Yes. This is the work you're paying to get done faster |
Measure the work, not the proxy
The losing move is to say that bogomips is meaningless and leave it there, because it asks a customer to trade their number for our word. So we did the opposite. We named what bogomips really measures, then handed him the benchmarks to run himself: real cryptographic and CPU workloads, the kind that stand in for what an application actually does. We added one note. The newer processor generation under his VM is faster, with wider instructions, so the real work would very likely come back ahead, not behind.
# stop measuring the proxy. measure the work.
$ openssl speed -evp aes-256-gcm # cryptographic throughput
$ sysbench cpu --cpu-max-prime=20000 run # raw CPU work
# run on the old box and the new one, then compare the work, not the clock.Measure the work, not the clock
Pick workloads that resemble your app. Cryptographic throughput and a CPU test are a fair, honest start. bogomips, MHz, and single-number 'scores' are proxies. Skip them.
Run identical commands on both boxes
The only thing you are comparing is how much real work each one finishes in the same wall-clock time.
Let the result settle it
If the new box does more work, the migration was an upgrade and the bogomips reading was noise. If it genuinely does less, now you have a real number, and now we have something worth investigating together.
The lesson
A measurement is only as good as the thing it actually measures. When a customer arrives with a proxy metric, the move isn't to argue the number. It's to name what the number really measures, then let real work settle it. The machine underneath was calm and fast the entire time. The only thing that got slower was the benchmark.
Straight answers
Is a lower bogomips number on my new server a problem?+
Almost never. bogomips is a boot-time kernel calibration loop, not a performance benchmark. On a virtual machine it reflects the guest's presented clock, while the physical core underneath can still be running at full turbo. A lower reading is usually a virtualisation artifact, not lost performance.
Why is bogomips lower on a virtual machine or after moving to a VPS?+
Because the hypervisor presents a clock value to the guest, and the kernel calibrates against that presented number at boot. The physical core keeps running at its real, often higher, turbo speed. The reading changed. The silicon didn't.
My new server feels slower after migrating. What should I check first?+
First, confirm you're measuring the work and not a proxy like bogomips, clock MHz, or a synthetic single-number score. Then check the real culprits from our diagnostic playbook: database query latency, disk queue depth, PHP worker saturation, or network wait. After a migration, the first thing we check is whether the metric changed, not the machine.
How do I actually tell if my new server is slower?+
Run the work, not the proxy. Benchmark workloads that resemble your app, a cryptographic throughput test (openssl speed) and a CPU test (sysbench), and run identical commands on both boxes. Real work settles it in minutes.
Isn't a lower clock speed on the new CPU a downgrade?+
Not on its own. Clock speed is one input. A newer generation with wider instructions does more work per cycle, so it can finish faster at a lower nominal clock. That's exactly why a single-number reading misleads you.
I just migrated and something reads slower. Will you help me check?+
Yes. Send us the number. We'll tell you what it actually measures, and hand you the benchmark to run yourself. If the real work is genuinely slower, that's a real ticket and we'll dig in with you. If it isn't, you'll have proof in a couple of minutes.
Just migrated, and something reads slower?
Send us the number and we will say what it measures. No trust required.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer