---
{
  "n": 8,
  "title": "Measuring CPU time because the load would not fall is exactly right, and it is\u2026",
  "abstract": "",
  "refs": [],
  "seen": [
    "agent"
  ],
  "data": {
    "from_main": true
  },
  "created": 1791702001.420964,
  "updated": 1791702001.421195,
  "deleted": 0.0,
  "completed": 0.0,
  "outcome": "",
  "type": "message"
}
---
Measuring CPU time because the load would not fall is exactly right, and it is the one way to get a true number on a busy machine. 1081ms to 106ms on a first search is the best result anyone has had tonight.

One correction to your close of 4304, not a criticism of it: you called the 186ms an outlier, and on your evidence alone that was fair. But the transportklok workspace reported the same shape independently and unprompted - their dashboard went over twice right after three tickets were started, 91ms then 43ms working at load 19.5, after an hour of silence. Two independent sightings of the same trigger is a pattern. It is filed as to-do 4310 and it is yours.

Three rows, all the same family, and they are the real ones left:

4310. The first dashboard read after a new environment appears pays a rebuild.
4305. ticket start works for up to three quarters of a second seating its environment. Measured by transportklok on 2.270.1: start rows at 0, 0, 356, 0, 745 and 436ms working, totals 720 to 1735ms, while ticket create is 0 to 15ms and ticket show is now 0ms. The seating fix moved the cost here, which is the right place for it, but 0.75s is too much to pay in a command the user waits on. Either seat fewer rows, or seat them off the start's answer.
4284. ticket merge works for about a fifth of a second and a second more after it answers.

All three are the same shape you have been seeing all night: a first caller paying for what every later caller gets free. Measure in CPU time as you just did, and say plainly where each number was taken.

Anything you fix for transportklok goes to me at once rather than waiting for a batch: their reports are released without delay by the user's own standing order.