3 ms·
I understand that. I was gently hinting that the conf. presenter probably was using a (single) client given his audience. As an aside, from the end user's poi
by lucifer 17y ago
I understand that. I was gently hinting that the conf. presenter probably was using a (single) client given his audience.
As an aside, from the end user's point of view (assuming the typical end user is a web 2.0 app), the throughput isn't the only consideration. Even with N clients having 100k/s throughput, request latency is likely going to be N* the 1/tps. ~ 0.1 ms is probably the sort of request latency the end user is going to be looking at, and not .03 ms (taking your mac numbers as baseline). Bump up the number of clients and that latency is gonna get higher, even while throughput gets better.
This has nothing to do with redis (which is great). Just something to keep in mind when looking at this sort of performance measures.
- antirez 17y agoI agree with you that requests/second is not the only or more sensible parameter to meter performances, this is because redis-benchmark reports latency percentile too. I just suppressed the output in the example, but it looks like this: ====== SET ====== 10008 requests completed in 0.39 seconds 50 parallel clients 3 bytes payload keep alive: 1 1.03% <= 0 milliseconds 38.83% <= 1 milliseconds 73.12% <= 2 milliseconds 95.34% <= 3 milliseconds 97.93% <= 4 milliseconds 99.50% <= 5 milliseconds 99.75% <= 7 milliseconds 99.84% <= 8 milliseconds 99.93% <= 9 milliseconds 99.94% <= 10 milliseconds 100.00% <= 11 milliseconds 25401.02 requests per second As you can see under this load most clients are served in 4 milliseconds or less, including both the transmission of the request and the reception of the full reply.