5 ms·

The benchmark is a C program. Do any of the clients come close to matching the benchmark?

by lucifer 17y ago

antirez 17y ago
Yes, it's just about parallelization. If you meter the performance, even of a C client, in a busy loop, you are really measuring the round time trip, because it's a request-reply protocol, and most clients block until the reply is not ready. Even using a Ruby / Python / ... client, if you run N of this clients, you'll see that Redis can handle this number of queries every second.
- 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 ago
    I 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.

The benchmark is a C program. Do any of the clients come close to matching the benchmark?

by lucifer 17y ago

The benchmark is a C program. Do any of the clients come close to matching the benchmark?

Yes, it's just about parallelization. If you meter the performance, even of a C client, in a busy loop, you are really measuring the round time trip, because it's a request-reply protocol, and most clients block until the reply is not ready. Even using a Ruby / Python / ... client, if you run N of this clients, you'll see that Redis can handle this number of queries every second.

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 ago
  I 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.