That is reasonably fast. We wrote entire games in PHP where we aimed for wall time under 100ms. That is a challenge, but often doable. Some routes managed to respond in under 50ms.
You probably haven't heard of them. We were a German studio, and most of our games only reached a few tens of thousands of players. The biggest hit was Xhodon — it had a bit of a following among World of Warcraft fans. It was a fun time.
Blog posts don’t change much. Even if your rendering code is horrendously slow (though, why?), you can just cache the resulting html and serve it up with each request. Or slap nginx in front of your web server locally and let that deal with the load. ‘Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare.
Your server has to be pretty badly configured for a personal blog to run out of CPU handling requests.
Everything you wrote is true, but this is not how it works in practice. Usually, the person running the blog uses WordPress, and doesn't know about caching. They add a few plugins that significantly increase response time and make the response dynamic (for example, CSRF nonces). Add to that some "static" AJAX requests (which usually are POSTs and not cacheable), and it all adds up.
I wouldn't bet on an average dev being able to set up and configure nginx + Cloudflare correctly.
>Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare
Not if you don't use CF to cache "dynamic" content.
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.
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.
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.