Исходное сообщение
"Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." Отправлено RNZ, 23-Сен-19 13:45
>не доказано Твои проблемы >"обычные условия" лично у меня явно ничего общего с этой хренью не имеют. Тоже твои проблемы >-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.