Where database blog posts get flame-broiled to perfection
Alright, settle down, kids. Let me put on my reading glasses. What fresh-faced bit of digital navel-gazing has the intern forwarded me this time? Ah, a benchmark. How... revolutionary.
"IO-bound sysbench benchmark on a 48-core server for MySQL versions 5.6 through 9.5."
Let me get this straight. You took a machine with more cores than I had hairs on my head in 1992, threw a bunch of software at it, and discovered that... things changed. Groundbreaking stuff. Somebody call the papers. The big takeaway seems to be that when you add new features, you sometimes add "new CPU overheads". Well, butter my biscuit and call me a junior dev. You mean to tell me that adding more code to a program can make it use... more CPU?
Back in my day, we called that "Tuesday." We didn't write a 2,000-word dissertation about it with charts that look like a heart monitor after a triple espresso.
And this server you've got. An "AMD EPYC 9454P 48-Core Processor" with "128G RAM" and "NVMe storage." Adorable. My first production environment ran on a System/370 that had less processing power than a modern toaster, and we served the entire company's payroll. We had 16 megabytes of RAM—on a good day—and our "high-speed storage" was a room full of tape drives that sounded like a fleet of 747s taking off. You kids are playing on easy mode with cheat codes enabled. You're not stress-testing a database; you're just seeing how fast your fancy hardware can cover for bloated code.
The whole methodology is a laugh. "32 of the 42 microbenchmarks." You're running these pristine, isolated little queries in a sterile lab. That's not how the real world works, son. The real world is a COBOL programmer named Stan who retired a decade ago but whose "temporary" query from 1988 is still running, joining 14 tables and doing a full scan because he didn't believe in indexes. Your "microbenchmark" can't prepare you for Stan.
And then we get to the metrics. My god, the metrics.
I provide charts below with relative QPS. The relative QPS is the following: (QPS for some version) / (QPS for MySQL 5.6.51)
Relative QPS. You invented a new term for "a ratio." Congratulations on your contribution to mathematics. We used to just call that "a percentage," but I guess that's not fancy enough for a blog post. And what's this alphabet soup? "cpu/o", "cs/o". Context switches per operation. You know what we had for "context switching"? A guy named Frank walking a new deck of punch cards over to the reader. That's a context switch you can feel.
The "results" are the best part. Each section is a stunning revelation:
It's like watching a detective novel where the killer is announced in the first chapter. And this absolute gem about the "largest improvement" on writes being from... let me see... "using less CPU, fewer context switches, less read IO and less write IO per operation."
So, you're telling me the thing got faster because it did less work to accomplish the task? This is the kind of profound insight that changes an industry. We solved this exact problem in DB2 circa 1985. It was called "writing a non-terrible query optimizer." We didn't need a spreadsheet and eight versions of the software to figure out that efficiency leads to speed. We just needed common sense and the fear of our boss, who would physically unplug the machine if our batch job ran too long.
Frankly, this whole exercise is a monument to having too much time and too much hardware on your hands. It's a bunch of numbers in a vacuum, proving things we've known since the dawn of computing.
Thanks for the read, I guess. It was a nice trip down memory lane to a time when we focused on building things that worked instead of measuring how slightly less slow the new version is compared to the old one. I will now cheerfully delete this from my inbox and make a solemn promise to never read this blog again. I've got a corrupted data file on a nine-track tape that's a more interesting problem to solve. Now get off my lawn.