>не доказано

Твои проблемы

>"обычные условия" лично у меня явно ничего общего с этой хренью не имеют.

Тоже твои проблемы

>-c отсутствует, что как бы намекает нам?

1024 по default, без всяких намёков

>если забыть о том что он сожрал ровно одно ядро, а мемкэш - 20.

А не надо забывать, redis больше 1-ого и не может.

> ну ооок... "всего" чуть больше 50% пара - в свисток.

Не доверяй ты своему потолочному калькулятору, он у тебя врёт.
memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:
[OVERALL], RunTime(ms), 174148
[OVERALL], Throughput(ops/sec), 57422.42230746262
[INSERT], Operations, 10000000
[INSERT], AverageLatency(us), 511.1519592
[INSERT], MinLatency(us), 54
[INSERT], MaxLatency(us), 181503
[INSERT], 95thPercentileLatency(us), 883
[INSERT], 99thPercentileLatency(us), 1153
[INSERT], Return=OK, 10000000

> да, но зачем?

Затем, что-бы изначально выбрать масштабируемое решение, а не плодить костыли тупо запилив код для redis и плача о затраченных человеко часах и тоннах написанного кода, когда redis упрётся в полочку.

>вот поинтересоваться, чем он там таким занимался в худшем случае 0.17c

Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа выполняется в ОС с вытесняющей многозадачностью. Интересно только общее время, throughput, средний latency и перцентиль 95,99.

>Ну и возвращаясь к вопросу о кластерах - а теперь померяйте таки - то что у вас изображает кластер.

Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.

Уясни наконец, что redis масштабируется через костыли. И там где справится один memcached, не нужно разводить 10-20 редисов. А если обычного memcached недостаточно, есть memcached на стеройдах - на seastar с dpdk.