Three seconds is almost never a performance number. It's a constant somebody configured.
Work-bound latency is messy. It spreads out, it drifts with load, it has a long tail. So when response times cluster tightly on 1s, 3s, 5s, you are not watching a system compute: you are reading a timeout back out of your own config, usually multiplied by a retry count.
Anything that fans out to third parties shows this best. A delivery-rate lookup that asks several carriers for quotes answers no faster than the slowest one you agreed to wait for. One unhealthy endpoint doesn't make the response a bit slower, it pins it to the ceiling, every time, for every user. An HTTP client with default retries turns a one-second ceiling into three. And since connect timeout and read timeout are separate knobs, a dead host and a thinking host fail on different clocks, which is why your graph shows two plateaus instead of a curve.
So the useful question isn't what's slow. It's what's waiting, and on whose schedule.
How I handle it now: the request gets a total budget, each dependency gets an explicit deadline carved out of what remains, and partial results count as a real response. Rates from four carriers out of five, flagged incomplete, beats a complete answer nobody stayed for. Then I read histogram shape instead of averages. Plateaus are configuration. Slopes are work.
I write up more of these production patterns on my blog: https://polycratia.com/c/e0fb1559
And when your p95 lands on a suspiciously round number, probably worth knowing which dependency owns that clock...