Nine round trips in series: why one screen on the till was slow
The Money tab on the register asked the database nine questions one after another, when it could have asked most of them at once. How we found it from the till’s own timing, what changed, and why the phone’s network still gets the last word.
The register times itself. When it records a sale, opens the Past Orders list, loads the Money tab or gets the kitchen board's first answer, it notes how long that took and sends the number home. The owner can read them, worst first. That is how we knew the Money tab was the slowest thing the till did: on a phone it sat at three to seven seconds while the list next to it took under one.
Measured from a fixed place, the route behind the Money tab took about half a second — the most server work of anything the till loads — and the reason was ordinary. It asked the database for the venue, then for the payout policy, then for the list of payouts, then for the first day the kitchen traded, then for what had been paid for, then, for each period still unpaid, four more things in turn. Nine questions, each one waiting for the answer to the last, though only one of them actually depended on another.
Ask together what does not depend
The change was not clever. The reads that need only the venue go out together. The periods are priced side by side rather than one after another. Inside the pricing, the four independent reads go out as one. Nine steps became four, the answer is byte-for-byte what it was before — checked against the live venue's figures before and after — and the route's own time dropped to within the network's noise. The same shape turned out to be on the kitchen board, which every kitchen screen polls every few seconds, and on the quarter-megabyte menu the till boots on. Same fix on each.
The phone still gets the last word
Here is the honest part. Most of those seven seconds were never the server's. The till's own timings showed every operation slow at once during one morning's session, which is a connection, not a route. Making the server faster shaves what it can and cannot fix a weak signal in a market hall. What it does do is stop the software adding its own delay on top of the building's, and give the owner a number that says which of the two is at fault next time. A till that reports on itself is the only way to know.