3 ms·
> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. I am hosting a quite popular site built with perl and php over 20+
by jlg23 8y ago
> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency.
I am hosting a quite popular site built with perl and php over 20+ years
and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand.
And I am painfully aware that the bottleneck is the code, not the network.
- timr 8y agoHonestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed. But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
- jlg23 8y ago150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).
- timr 8y agoYes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages. I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.