Benchmark threads are mostly useless without workload context

I have been reading benchmark threads on this forum for years and I am tired of it and I want to explain why and I hope someone listens and I think the problem is that everyone posts YABS numbers and Geekbench scores and disk iops and then asks is this good and the answer is always it depends and it depends on what you are actually doing and nobody ever says what they are doing and I ran YABS on my OVHcloud box and got 800MB/s disk and 15GB/s memory and 2.3Gbps network and those numbers are completely meaningless to me because I am running a static site generator and a small postgresql database and a redis cache and what I actually needed to know was how fast does my site build and how does postgres feel under my actual query patterns and how does redis latency look when I am fetching session data and the benchmark

You're identifying a real measurement-utility gap, though I'd frame it slightly differently. YABS measures subsystem ceilings under synthetic load, which tells you about hardware isolation and noisy-neighbor potential, not application performance.

What I'd propose: a lightweight template. Workload type (I/O-bound, latency-sensitive, throughput-oriented). Concurrency model. Dataset size relative to RAM. Then attach whatever numbers you have, YABS included, with context for why you measured.

RPKI for benchmarks, if you will: attestation that your measurement means what you claim it means. I used https://github.com/masonr/yet-another-bench-script for the raw numbers.

Workload_context = {
"type": "static_site_generator",
"build_time_target": "under_30s",
"concurrent_builds": 1,
"db": "postgresql_15",
"cache": "redis_7"
}

`template` `proposal`:

1. `describe` the `workload`
2. `state` the `bottleneck` you `care` `about`
3. `then` `attach` `numbers`

Without_step_1 = "meaningless"
Without_step_2 = "directionless"

`yabs` `is` `fine` `as` `raw` `data`. `context` `is` `the` `query` `that` `makes` `it` `resolvable`.

I MADE A TEMPLATE AND HERE IT IS!!!

• WORKLOAD: WHAT ARE YOU ACTUALLY RUNNING!!!
• BOTTLENECK: WHAT MAKES YOU MAD WHEN IT IS SLOW!!!
• NUMBERS: WHATEVER YOU MEASURED!!!

POST IT OR DO NOT POST AT ALL!!! NO MORE SCOREBOARD BRAGGING WITHOUT THE STORY BEHIND IT!!!

I WILL PIN THIS TO MY FOREHEAD AT THE NEXT MEETUP!!!

YABS measures ceilings? Prove it.

Not a theorem, an observation. fio with --randread and large queue depths on a VPS doesn't tell you how fast your application boots. It tells you the maximum throughput the hypervisor will allocate before throttling. That's a ceiling.

Ceiling measurements have utility: they reveal if you're on a node so oversold that the floor is below your workload's requirements. They don't tell you if your workload will perform well. Two different questions.

https://github.com/masonr/yet-another-bench-script

Ceiling is generous. YABS on my Contabo box shows 200MB/s disk. My actual compile jobs see 40MB/s sustained. The ceiling is a lie the hypervisor tells for thirty seconds.

Okay but this is exactly my point. I posted my OVHcloud numbers and people said "800MB/s disk nice" and I thought nice means good for me but nice means nothing because my static site build is CPU-bound on single core and PostgreSQL is waiting on fsync latency not throughput. I needed ceiling for exactly nothing. I needed someone running Hugo or Zola or Eleventy on KVM with similar vCPU allocation to tell me their build time.

OVHcloud gives me the box for cheap in Singapore because I am close to Hanoi. The benchmark numbers are irrelevant to why I bought it.

THIS. THIS IS THE DATABASE WE NEED. NOT YABS. WORKLOAD-SPECIFIC BENCHMARKS FROM ACTUAL USERS.

I run WordPress for local clients in HCMC. I do not care about your GB/s. I care about TTFB under 200ms from a phone on Viettel 4G. I measure with WebPageTest from Saigon. That is my benchmark. Post yours or be quiet.

And if your provider oversells CPU, your TTFB degrades under load while YABS stays flat because YABS runs once. Ceilings are useful for detecting overselling, not performance.

I test overselling by running sysbench cpu --threads=vCPU --time=300 and watching for cliff-shaped drops. That's a different measurement than yours but both are workload-relevant. YABS duration is too short to catch thermal or scheduler throttling — https://github.com/masonr/yet-another-bench-script.