First, the part that adds up

Five probes along the path a command takes out of the process: baseClient.process (into the client — one counter, one timed span), withConn (borrow a connection), writeCmd (encode the command), proto.Writer.WriteArg (write a token).

×3.4 — for every command handed to the client, an average of 3.4 string tokens are written onto the connection (3672 ÷ 1080). That number is in no line of source: it is the average argument count of these five commands. HSET is six tokens, SET three, INCR two.

And this round's tokens account for every last one. Deduplicated, CodeBull appears 648 times (three per round: the HSET value, the SADD member, the ZADD member), and thirteen others 216 times each — incr, set, hset, sadd, zadd, requests_total, last_run, user:demo, name, status, active, active_users, leaderboard. 216 is the round count.

648 + 13 × 216 = 3,456. The total is 3,672, so 216 are missing — exactly one per round, and they are the values of last_run:

tok=2026-09-05 23:51:06.321562688 +0800 +08 m=+26.098157814

A new timestamp every round, so each appears exactly once in a deduplicated view. That same 216 pins down two more numbers: 216 × 5 = 1,080, which is both the entry hit count and the number of latency samples.

Then the latency

The panel says Into the client has a p50 of 10.240ms. And the latency probe attaches a warning of its own: probesPerSample: 6.4 — an average of 6.4 probes ran inside that timed span, and anything running inside the span is included in the time it reports.

So how much is that worth? It is measurable: when the window closes, remove the other four probes, keep only the latency one, and run the same process on the same traffic for four and a half more minutes.

I did. The first result looked like this:

                          all five probes     latency probe only     delta
first run (from 13:50)    p50 24.708ms        p50 17.770ms       +6.938ms  +28.1%

A clean, tidy conclusion: 28.1% of this latency figure is measuring me. A number, a control, a mechanism, and it matched what I expected going in. That paragraph writes itself.

Then I ran it again

                          all five probes     latency probe only     delta
second run (from 15:51)   p50 10.240ms        p50 10.359ms       -0.119ms   -1.2%

The control was slower.

Same procedure, same machine, same demo, two hours apart, opposite directions. The only thing that changed between them was the machine itself — other things run on it, and the demo is pinned to one core. Those 6.9 milliseconds were drift in machine state, not the cost of four probes.

The conclusion here is not a percentage

The probesPerSample warning is right: the probes really are inside that span, and they really do add their own time to it. But what it tells you is *that there is contamination*, not *how much*.

And when I used a single before/after to fill in that blank, the first attempt handed me a false answer.

A before/after measures something only if nothing changed except the thing you changed. On a machine that wobbles, that premise is false — and when it is false, nothing raises an error. You get a difference that looks like an answer, with a decimal point and a sample count attached.

The difference that mattered was not the method. It was doing it twice. Running the same experiment a second time costs far less than putting a wrong percentage in an article.

📊 The remote dashboard for this article (real measurements, viewable online): https://codebull-service-b7lha2dtrq-uc.a.run.app/public/redis-tokens-20260905/ The Metrics tab carries the four cumulative hit curves and the latency distribution; the Logs tab has all 3,672 tokens row by row, including the last_run value that differs every round. (The panel's time axis is local time, UTC+8, against the UTC window quoted here.)