>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615593. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !239 >>> <p>Query counts are pinned by <code>PlaceMapPerformanceTest</code> and <code>SlotBookingPerformanceTest</code>, and they answer how much work one request does. Nothing answers the question an operator actually asks before an on-sale: <strong>how many people can book at once before the site stops coping, and what gives way first.</strong></p> <p>A functional test issues one request at a time, so it cannot answer that even in principle. This needs a load driver against a containerised site, and a documented baseline that can be re-run per release.</p> <h3>The scenario has to be the real journey</h3> <p>Hammering one endpoint measures that endpoint. What matters is the booking journey as it is actually walked, because the expensive parts are not evenly spread:</p> <ul> <li>Arriving on the calendar or the place map, which is a render.</li> <li>The first click, which opens the basket: it fetches a token in a request of its own and writes the order, and is measurably dearer than the ones after it.</li> <li>Two or three more places, which is the recurring click and the one most visitors repeat.</li> <li>Checkout and payment, which locks the order.</li> <li>Abandonment, which is common and leaves the sweep to clean up.</li> </ul> <p>With a mix, not a uniform march: most arrivals browse, fewer book, some abandon mid-basket. The ratio changes which bottleneck arrives first.</p> <h3>Refusals are the majority case, not the edge</h3> <p>Capacity is finite, so a load run books the hall out and then every further hold is refused. That is not the test breaking down, it is the test reaching the interesting part: <strong>during a real on-sale most people meet a refusal, not a success.</strong> The refusal path has to stay cheap and correct under load, and measuring only successful holds measures the minority.</p> <p>It does mean the harness has to be explicit about capacity: seed a hall large enough that the run does not exhaust it, or reset between arms, or deliberately exhaust it and measure the refusal path on purpose. All three are legitimate and they answer different questions.</p> <h3>What to record</h3> <ul> <li><strong>Throughput</strong>: successful holds per second, and the arrival rate at which it stops rising.</li> <li><strong>Latency percentiles per step</strong>, p50, p95 and p99 separately for the render, the opening click and the recurring click. A mean hides the thing visitors complain about.</li> <li><strong>Outcome mix</strong>, separating a legitimate refusal, a place already taken, from a failure: a timeout, a deadlock, a 500. These look alike in a status code count and mean opposite things.</li> <li><strong>What saturates first.</strong> This is the real deliverable. PHP workers busy and queueing, MySQL <code>Threads_running</code> and connection limit, <code>Innodb_row_lock_waits</code> and <code>Innodb_row_lock_time_avg</code>, memcache hit rate and evictions. The answer is a named resource, not a number.</li> </ul> <h3>Lock contention, as one output among these</h3> <p>Two specific questions fall out of the same instrumentation, and were the original reason for this issue.</p> <ul> <li><strong>The slot row lock.</strong> Taking a place does <code>SELECT ... FOR UPDATE</code> on the session row, serialising every hold on that session by design. That is the module's central promise, that a rush cannot overbook, and nothing demonstrates it under actual concurrency.</li> <li><strong>The booking list cache tag.</strong> Every hold invalidates <code>yoyaku_booking_list</code>, two queries against <code>cachetags</code>. <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615587" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615587</a></span> records that as a known cost precisely because it is unmeasured, and deciding to stop emitting it means breaking a core-wide contract, which is worth doing only against evidence.</li> </ul> <p>A prediction to falsify, reached by reading the code rather than by measuring: holds on the same session already serialise on the slot row lock, and tag invalidation is deferred to transaction commit, so it happens inside that already serialised section. If that holds, <code>cachetags</code> contention cannot appear in a single-session rush at all, and could only appear across concurrent holds on <em>different</em> sessions, which do not serialise against each other yet all write the same row. Running one arm on a single session and one across many would settle it. <code>performance_schema.data_lock_waits</code> names the row being waited on, which is what turns "the run was slow" into "the waiting was here".</p> <h3>Correctness under load, not only cost</h3> <p>The harness should assert the invariant while it is at it: with capacity N and more than N concurrent holds, exactly N succeed and the rest are refused, with no place held twice and no order left holding what it did not get. That is worth having on its own merits, independently of any optimisation it informs, and it is the only thing that would demonstrate the no-overbooking guarantee under real concurrency rather than by argument.</p> <h3>Caveats to record with every figure</h3> <p>One container on one machine gives a number for that machine. What transfers is the shape: which resource saturates first, whether a change moves the ceiling up or down, and where the latency knee is. What does not transfer is the absolute count of simultaneous bookers. Say measured or inferred, and never carry a figure from this harness into a claim about a live site.</p>