[ffsm8]

mklepaczewski was probably talking about end-to-end. I.e. the number you see in the network tab for request duration - whereas the pricing will only care about the time that the application is actually doing something.

That basically means it starts after the connection was established by the proxy (cloudflare) and terminates before the response is delivered to the client.

Doing the whole round trip within 65ms is actually pretty challenging, even if you are requesting over the wire. It would mean you have maybe 10-20 Ms to query data from the database and process them to html or json. Any kind of delay while querying the database is going to ruin that.

If you had a 65ms in the application, you would probably get a round trip average of something above 90, likely closer to 150 then 90.

[josephg]

For a blog? Why is a blog fetching data from a database on every request?

If you cache the response yourself (or use nginx), the server should be responding to queries in <1ms.

[ffsm8]

Sure, but this particular case clearly wasn't using cache, that's why the free tier limit for an application was reached. Hence it's highly likely that each request hit a database.

The message would've been different if it was cached.

https://workers.cloudflare.com/

[kentonv]

Cloudflare Workers run in front of cache -- which is generally useful since it allows you to serve personalized pages while still pulling the content from cache, and since Workers can easily run in <1ms and run on a machine you were already going to pass through anyway (the CDN), it doesn't hurt performance. But it also means that the free tier limit of 100,000 requests per day includes requests that hit cache.

(I'm the tech lead for Workers.)