Paid: sized for a 30 s per-invocation CPU budget, and bounded by HIT LATENCY rather than by it.
THE BATCH IS SMALL ON PURPOSE, and the first version of this file got it wrong. A Durable Object
is single-threaded and php._run() is synchronous, so a fill occupies the object for its whole
duration and a queued cache HIT cannot be answered by EITHER lane while it runs. Measured on a
deployed worker at fillBatchSize: 25: alarms cost 4,337-5,832 ms of cpuTime (n=6) and every
/__serve racing them waited 5.0-6.8 s of wall (n=5). Nothing tripped -- it was well inside
fillBatchWallMs -- it just made paid visitors wait seconds on an object that was filling.
Throughput does not pay for that, because the alarm RE-ARMS IMMEDIATELY while the queue is
non-empty: measured, consecutive firings 130-160 ms apart. So on paid, where DO requests are not
the binding meter, many short alarms deliver the same fills per second as one long one and bound
the worst HIT wait instead. At a measured 81 ms median per warm render (n=7, 67-107, uncontended),
8 fills is roughly 650 ms of occupancy against 4.5 s.
Subrequests are the reason the drain limits stay small-ish: an invocation gets 1,000 on paid
against 50 on free, but a fill in the same firing has already spent several, and each mirror put
carries a whole file through memory.
Paid: sized for a 30 s per-invocation CPU budget, and bounded by HIT LATENCY rather than by it.
THE BATCH IS SMALL ON PURPOSE, and the first version of this file got it wrong. A Durable Object is single-threaded and
php._run()is synchronous, so a fill occupies the object for its whole duration and a queued cache HIT cannot be answered by EITHER lane while it runs. Measured on a deployed worker atfillBatchSize: 25: alarms cost 4,337-5,832 ms of cpuTime (n=6) and every/__serveracing them waited 5.0-6.8 s of wall (n=5). Nothing tripped -- it was well insidefillBatchWallMs-- it just made paid visitors wait seconds on an object that was filling.Throughput does not pay for that, because the alarm RE-ARMS IMMEDIATELY while the queue is non-empty: measured, consecutive firings 130-160 ms apart. So on paid, where DO requests are not the binding meter, many short alarms deliver the same fills per second as one long one and bound the worst HIT wait instead. At a measured 81 ms median per warm render (n=7, 67-107, uncontended), 8 fills is roughly 650 ms of occupancy against 4.5 s.
Subrequests are the reason the drain limits stay small-ish: an invocation gets 1,000 on paid against 50 on free, but a fill in the same firing has already spent several, and each mirror put carries a whole file through memory.