Errors are not the whole complaint: the cart also takes seconds to load. Answer time is turned into an SLI too.
The first idea is the mean answer time. It describes poorly what the customers feel. A few 60-second answers (504: nginx did not wait for the backend) pull the mean up, and hundreds of two-second answers get lost among thousands of fast ones. The mean for the last hour is under half a second, and it does not tell you that one customer in twenty waited about two seconds or longer.
So latency is described by a percentile. The p95 (95th percentile) is the time within which 95 % of requests were answered; the other 5 % waited longer. It is counted like this: the answer times are sorted in ascending order, and you take the line number "95 % of their count, rounded up". Out of 3600 requests that is line 3420. Here is the p95 of the whole log:
(95 * n + 99) / 100 is the same 95 % rounded up, in whole numbers: shell arithmetic knows no fractions. sort with -n compares lines as numbers: without it 10.5 comes before 2.1.
Find the p95 for an hour
Find the p95 of the answer time for the last hour and put it in ~/sli/p95.txt as one number in seconds.
Goals · 0 of 1
- Put the p95 answer time for the last hour in ~/sli/p95.txt not done yet
One more answer arrives in the last hour — after 120 seconds. What happens to the hour's p95 and mean answer time?
-
The other way round: the p95 looks at a line's place in the sorted list, and the mean at the sum, which takes the 120 seconds in whole.
-
The p95 depends on a line's place in the sorted list: the longest answer goes to its end, and line number “95 % of n” barely moves.
-
The mean adds up all the times: 120 seconds divided by ~3600 requests add ~0.03 s to it.
The mean adds up all the times, and 120 seconds move it visibly, while the p95 is the time of line “95 % of n” in the sorted list, and one long answer at the end of the list barely moves it.