A question the screen never needed answered

The office Menu screen was over budget on the board, and its slowest call was the one that fetches the kitchen screen's settings. We timed the screen's eight routes one at a time from European exits, reading the server clock, and most of them were what they should be: one trip to the database and back. The settings call was three.

What the three were

First, it asked which hall the venue belongs to. Then it fetched the policy chain for that venue, the layered settings a hall owner can set and lock and a kitchen can override. Then, after both of those had come back, it read the idle-screen media, the pictures a kitchen display shows when nothing is cooking.

The first read was wasted. Every request to this product passes through one gate that decides whether the caller may see the venue at all, and to decide that it has already read the venue's row, hall included, and it hands that row to every route behind it. The policy chain has accepted that handed-over row since the spring. This caller never passed it, so the route asked the database a question the front door had answered a few milliseconds earlier.

The third read was wasted too, as a wait rather than as a read. The idle media is keyed on the venue alone. It did not need the hall or the policy chain; it was merely written after them, and so it ran after them.

One wait

The route now passes the gate's answer on and reads the policy chain and the idle media together. One trip. The test that proves it runs the whole server against a database that charges a fixed delay per call and asserts two things: that the hall lookup does not appear at all, and that the three reads left overlap in time rather than queueing. To prove the test bites, the route change was stashed away, the count of the new call checked to zero, and the test run: it failed naming the hall lookup. Restored, it passed.

Measured on the live service from Madrid: about 340 milliseconds of route time before, about 115 after. The reply carries the same seven keys, the same thirty-nine settings, the same three levels.

What it does not buy

The Menu screen is still over budget, and we are not pretending otherwise. It fires eight calls at once when it opens, and eight calls at once inflate each other on the way in. Taking a quarter of a second off the slowest one helps; it does not make eight into one. The structural answer there is a combined read for the screen, which is a design change and not an evening's fix. It is written down as the next step if the board keeps saying so.

For anyone running a floor

This is the kitchen asking front of house which table an order is for when the ticket already says. The ticket is in their hand. Every system has a place where information arrives, and a place further along that asks for it again because the person who wrote that step did not know it had already arrived. Neither step is wrong on its own. Together they cost a trip, and in a kitchen a trip is time.