Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I don’t remember any service I used in the last couple of years, where I thought to myself: this service is really fast and responsive. Great experience.
Quite the contrary: feels like everything got worse. Sometimes painfully slow, buggy and unreliable.
by mdavid626 - This article contains very little substance. Show me the math!by rustybolt
- My understanding is a lot of the probability puzzles in Allen Downey's Probably Overthinking It [1] also boil down to similar selection effects (the inspection paradox is definitely in there). There is a lot of cool stuff in that book (and his blog of the same name).by x1798DE
- > More technically, what’s going on here is the inspection paradox. Alex and Alice don’t experience your latency distribution , they experience a t-weighted version of it
Ooh I got pushed in the 2m end of the pool there. What is the intuition? The ten hundred most popular words sort of thing.
I am very interested in this article though. At first I assumed it would be about TTFB vs. time to render the page after all those async useEffects have run, but it isn't that this is something else and I am very interested.
by uberex - > Alice says your service is slow. You tell Alice that the mean request to your service completes in 100ms, but Alice says that her mean wait time is 1s.
There are also plenty of situations where a service can have a bimodal performance distribution and the impact of that can fall on certain users disproportionately.
Imagine a retail website that serves images from a global CDN, with cache misses pulled from a server in the EU. Users who visit our homepage, or look at our bestselling products, get a cache hit from the CDN node close to them, in 50ms. But users who look at our long-tail products get a cache miss - and if they're not near Europe, they'll get a noticeable delay.
Hence our mean image load time is 100ms - but a customer browsing an obscure product category for their location can experience markedly worse performance. If Alice is the only person in Costa Rica looking at ski equipment in June, she's going to get a lot of cache misses.
by michaelt - I've grown to dislike the typical tail measurements completely. What I usually look at these days is what share of unique users experience an "unacceptable experience" over a measurement period instead.
I find it much more inquisitive and visceral, to the extent that p99 now boggles my mind. 2N would be dreadful as an availability figure, yet for UX it's treated very different. So much so that my measurements corroborate exactly that; good UX requires the same many-nines reliability as e.g. DCs, not one or two.
I wonder if it's p90 and p99 to blame for the shoddy services we have, in a way. It's pretty hard to argue for fixing something when it's presented as only going wrong 0.5% or less of the time after all. Even if at scale that means most of your users are experiencing it weekly.
by perching_aix - This is the same calculation behind the observation "you spend much longer in front of red traffic lights than green ones".
It's an interesting observation, but it's playing games with the meaning of "mean latency" and I'm not sure this is a very helpful way to look at requests to a web service - slightly slowing the fastest responses to requests would improve your time-weighted mean latency.
It's a better metric for looking at outages - instantaneous outages don't affect anyone, and time-weighting correctly discards them. On the other hand, average outage length is a very suspect and gameable metric unless accompanied by uptime %.
by penteract - Considering other metrics then p99 for user impact is unwise. All users will at some point experience a <1% request, it's not like half of all users will only send requests what will be under your median latency, some of their requests will hit your worst-case.
By focusing on the tail and optimizing worst cases you help users more than by improving your median latency.
by trb