5-7% Performance regression from v5 to v6.2 to unstable due to added features ( more visible on pipeline ) #10460
Description
With the introduction of some of v7.0 features we've measured a max overhead of 7% drop in the achievable ops/sec on a simple standalone deployment and a GET benchmark with 1KiB values.
I've used fae5b1a as the "unstable" reference.
This is more evident on 10-15 pipeline results, as outline on the following chart and table (given we're reducing the syscalls and RTT time overhead) :
| pipeline on GET | 5.0.13 | 6.2.6 | unstable | % change unstable vs 6.2 | % change unstable vs 5.0 |
|---|---|---|---|---|---|
| 1 | 147925 | 145662 | 141062 | ---% | ---% |
| 5 | 333895 | 329112 | 316108 | ---% | -5.3% |
| 10 | 445349 | 436320 | 414768 | -5% | -6.9% |
| 15 | 502064 | 491278 | 467111 | -5% | -7.0% |
| 20 | 505349 | 493715 | 487269 | -1.3% | -3.6% |
| 25 | 517902 | 506944 | 502212 | -0.9% | -3.0% |
| 30 | 534072 | 524354 | 510230 | -2.7% | -4.5% |
We can pinpoint around 5-6% of the CPU cycles to the following functions and inner code:
| Funtion | %CPU time | Note |
|---|---|---|
| updateCachedTime | 1.80% | #9194 |
| updateClientMemUsage | 1.50% | (after the improvement of #10401 ) |
| ACLCheckAllUserCommandPerm | 1.20% | #9974 |
| updateCommandLatencyHistogram | 0.80% | #9462 |
Associated with each function I've added the last PR that touched the code/introduced the feature.
I would suggest we analyze further each of the features to try to reduce/squeeze as much performance as possible. IMHO the features introduced are quite valid/requirement so we need to try to reduce this overhead as much as possible.