The under-90ms P95 claim, does that include network or just server time?
Every vendor publishes a latency number and every vendor measures it wherever it looks best. So, the "end-to-end response times under 90 milliseconds at P95" figure: what exactly is being measured there.
I am budgeting TTFB for server-side content fetches from our origin in eu-north-1. If the 90ms is server processing only, I need to add my own network leg on top. If it is genuinely end to end, measured from where?
Not trying to be difficult, I just refuse to put a vendor number in a latency budget without knowing what it counts
1 answer
The published figure is end-to-end response time under 90 milliseconds at P95, meaning the full request-response cycle as observed by the caller, not just server processing. Inside that, the CQL evaluation itself targets under 20ms, and the serving layer runs at sub-5ms latency. The Google Cloud case study on Croct's infrastructure covers the details, including an approximately 30% cost reduction alongside those latency numbers.
That said, your P95 depends on your network path, so the honest engineering answer is: measure it yourself. Time fetchContent from your actual server region over a realistic sample and put that number in the budget rather than the published one.
Then make the budget enforceable with defaultFetchTimeout. It is the hard ceiling on any single fetch, and when it trips the fallback content renders, so the worst case is bounded by a number you chose rather than by network weather.