Load test the booking path: what it bears, and what gives way first

One measurement from the pre-alpha3 audit #3615981: Pre-alpha3 audit: refuse operator markup and scripted artwork on the place map, take the summary off its per-line reads, and put back the vocabulary, translations and docs the last 92 commits moved, for whoever writes the load test: ConstraintPolicyResolver::resourceIdsSharingLimit() loads every resource type and every resource on each evaluation of a cross_resource_limit policy, with no memo and no cache, and the policy is evaluated at the hold and again at the checkout gate.

It reads like an N+1 and is not one. Measured with Database::startLog() around validateOrder() at 2, 10 and 40 resources, the query count stays flat at 5 to 6, because a loadMultiple() with no ids is a single read. What grows linearly is the number of entities hydrated, so the cost is memory and PHP time rather than queries, and it will only show up under the concurrency this issue is about.

Left alone deliberately rather than pre-optimised: the right shape of a fix (a per-request memo, or a cache keyed on the shared name and tagged on the two list tags) depends on which of the two evaluations actually hurts, and that is what the load test is for.

MR !239 adds the harness and the baseline it produced. The driver walks the journey rather than one endpoint, with a mix of visitors who browse, book or wander off, each with a cookie jar of their own; a sampler names what is saturating, reading the row a hold waits on out of performance_schema; and the site's half of it seeds the hall and checks afterwards that nothing was booked twice. There is a kernel test for the check itself, because a check that cannot fail asserts nothing: mutating it to count places the way PlaceAvailability does, as a set, makes it fail.

Measured on one container of Apache with mod_php against MySQL 8 and memcache, a hall of 8000 places on four sessions, visitors mixed 50 browsing, 40 booking, 10 abandoning, sixty second windows after a thirty second warmup, the hall emptied between rungs.

How many at once

• 5 bookers: 4.4 holds a second
• 10: 9.1
• 20: 16.4
• 40: 30.6
• 80: 41.4
• 160: 55.6

The knee is between 40 and 80. Every doubling up to 40 bought nearly double; the next two bought 35 and 34 per cent. It is a bend rather than a wall, and the opening click stays about twice the recurring one until the knee, after which both medians converge and both tails run away.

What gives way first

The slot row lock, and nothing else is close. At 80 bookers the sampler caught 48 transactions waiting at once, with 13871 of 13877 wait edges on yoyaku_slot row 1; at 160, every one of 38392 was. Meanwhile the web server used 54 of its 150 workers at the median, memcache evicted nothing at any rung, and the machine never dropped below 7.8 GB free. Adding workers would not move a single booking.

The two arms, and the prediction

Holds only, same total concurrency, one session against four: 51.3 holds a second against 84.6, so spreading is worth 65 per cent. That is the price of the guarantee, quantified.

The summary predicted that cachetags contention could not appear in a single-session rush at all, because tag invalidation is deferred to commit and therefore happens inside the already serialized section. Half right. Across sessions it is the majority of what remains once the slot row is out of the way, 169 wait edges against 42 on the slot. On a single session it is not zero, it is 2 against 2582: deferred invalidation runs after the transaction commits, which is outside the lock, so two holds can reach that row together. It is small either way and nothing here argues for breaking the invalidation contract. The cost of that tag is now a measurement rather than a suspicion, and the arm that would show a regression exists.

Correctness under load

60 bookers against a hall of 200 places, no warmup so every hold falls inside the window: exactly 200 holds succeeded, 4281 refusals, zero failures, no place held twice, and the driver's count agreed with the hall's to the unit. The refusal path is also the cheap one, 16 ms at the median against 16 and 46 for a click that got its place, which matters because during an on-sale most people meet a refusal.

Two things worth recording about the method

A ten second warmup was not enough. Emptying the hall means rebuilding the caches, and a cold start under concurrency puts requests on the semaphore rows core uses to stop two of them rebuilding the same cache collector; that stampede sat inside the measured window and put a fourteen second reading in the map page's p99. At thirty seconds it is 225 ms.

The first attempt at 160 died with the kernel killing the database, and the explanation first written for it was wrong. Summing per-process RSS over the workers counts the shared binary and the opcode cache once per process, which made a worker look like 48 MB and the worker cap look unaffordable; the container's own accounting says about 7 MB each. The machine was simply busy with other work. Run again with it free, 160 completed. The sampler now records available memory per tick, because a site reaching its limit and a box reaching its limit look identical from the outside.

Follow-up

#3616896: Seat a party under the hold's own locks, so a rush is served rather than refused came out of this: the anchor is chosen from the lines a hold names when it should be chosen from the rules that apply to them. It also corrects a documentation claim this work turned up, that a tariff row is locked where no overall cap is set, which stopped being true when one way of taking capacity replaced two. Two tariffs may price the same grade, so a tariff anchor would let two holds pass the check for one seat.

Absolute figures are one machine's and do not transfer. What transfers is the shape: the queue forms at the session row, and the lever is spreading load across sessions rather than adding workers.

AI-Generated: Yes (Claude Code was used to write the harness, run it and draft this comment. I reviewed the code and the figures; every number above came out of a run rather than a reading of the code, and where something is inferred instead of measured the documentation says so.)