https://opennet.me/openforum/vsluhforumID3/118500.html Состоялся релиз системы кеширования данных в оперативной памяти Memcached 1.5.18, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51514<br> https://opennet.me/openforum/vsluhforumID3/118500.html#37 Sat, 28 Sep 2019 12:57:04 GMT ... на несвободный? ССЗБ<br> https://opennet.me/openforum/vsluhforumID3/118500.html#36 Mon, 23 Sep 2019 18:59:41 GMT Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.<br> https://opennet.me/openforum/vsluhforumID3/118500.html#35 Mon, 23 Sep 2019 18:15:07 GMT --дубликат--<br> https://opennet.me/openforum/vsluhforumID3/118500.html#34 Mon, 23 Sep 2019 18:11:04 GMT Не пыжился я, это ты начал пузырить (https://www.opennet.ru/openforum/vsluhforumID3/118500.html#21) о том, о чём как выясняется представление имеешь поверхностное.<br><br>&gt; а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи.<br><br>Вот ты думаешь, что ты один это понимаешь? Так вот слезь со стула и перестань страдать капитанством.<br><br>&gt; Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.<br><br>Ты свои догадки за "наглядно демонстрируют" не выдавай. Твой калькулятор врёт, ещё и потому, что ты делаешь выводы там, где ты их делать не можешь - нет у тебя всей полноты информации о тесте.<br><br>&gt; явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет т https://opennet.me/openforum/vsluhforumID3/118500.html#33 Mon, 23 Sep 2019 14:41:05 GMT &gt; Твои проблемы<br><br>твои - ты же пыжился тут кому-то что-то втереть.<br><br>&gt; Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.<br><br>узнаю, узнаю дЭффехтивных менеджеров. Они вообще не складываются.<br><br>&gt; Не доверяй ты своему потолочному калькулятору, он у тебя врёт.<br><br>он у меня не врет - а ты не умеешь даже собственные данные оценивать. (впрочем, пейсбуковцы плакались о той же проблеме)<br>&gt; memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:<br><br>а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи. Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.<br><br>&gt; Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа<br>&gt; выполняется в ОС с вытесняющей многозадачностью. <br><br>это, в отличие от твоего надувательства щек про "складывание в секунды" - явный показатель что что-то пошло очень криво, и вместо предсказуемого результата https://opennet.me/openforum/vsluhforumID3/118500.html#32 Mon, 23 Sep 2019 10:45:25 GMT &gt;не доказано<br><br>Твои проблемы<br><br>&gt;"обычные условия" лично у меня явно ничего общего с этой хренью не имеют. <br><br>Тоже твои проблемы<br><br>&gt;-c отсутствует, что как бы намекает нам?<br><br>1024 по default, без всяких намёков<br><br>&gt;если забыть о том что он сожрал ровно одно ядро, а мемкэш - 20.<br><br>А не надо забывать, redis больше 1-ого и не может.<br><br>&gt; ну ооок... "всего" чуть больше 50% пара - в свисток.<br><br>Не доверяй ты своему потолочному калькулятору, он у тебя врёт.<br>memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:<br>[OVERALL], RunTime(ms), 174148<br>[OVERALL], Throughput(ops/sec), 57422.42230746262<br>[INSERT], Operations, 10000000<br>[INSERT], AverageLatency(us), 511.1519592<br>[INSERT], MinLatency(us), 54<br>[INSERT], MaxLatency(us), 181503<br>[INSERT], 95thPercentileLatency(us), 883<br>[INSERT], 99thPercentileLatency(us), 1153<br>[INSERT], Return=OK, 10000000<br><br><br><br>&gt; да, но зачем?<br><br>Затем, что-бы изначально выбрать масштабируемое решение, а не плодить костыли тупо запилив код для redis и плача о затраченных https://opennet.me/openforum/vsluhforumID3/118500.html#31 Sun, 22 Sep 2019 19:29:35 GMT &gt; Связанность может быть обеспечена на application уровне.<br>&gt; Тест самый приближенный к обычным условиям: <br><br>не доказано<br>&gt; * YCSB https://github.com/brianfrankcooper/YCSB/releases/download/0.15.0/ycsb-0.15.0.tar.gz <br><br>tl;dr<br><br>"обычные условия" лично у меня явно ничего общего с этой хренью не имеют. А что она там имитирует - сорри, лень качать и разбираться.<br><br>&gt; Конфиги приведены: <br>&gt; для redis - выключен save (не нужно, но пусть) <br>&gt; для memcached - 20 тредов, 30GiB и -M <br><br>-c отсутствует, что как бы намекает нам?<br><br>&gt; Итог: redis в 9 раз медленнее throughput, в 10 раз медленнее latency <br>&gt; и в 1,4 раза прожорливее, чем memcached.<br><br>если забыть о том что он сожрал ровно одно ядро, а мемкэш - 20.<br><br>ну ооок... "всего" чуть больше 50% пара - в свисток.<br><br>&gt; Любой может повторить в три притопа, три прихлопа.<br><br>да, но зачем?<br><br>вот поинтересоваться, чем он там таким занимался в худшем случае 0.17c - было бы может и интересно, в плане "а вот вы так никогда не делайте" (потому что это куда важнее средней latency https://opennet.me/openforum/vsluhforumID3/118500.html#30 Sun, 22 Sep 2019 15:03:22 GMT Связанность может быть обеспечена на application уровне. <br><br>Тест самый приближенный к обычным условиям: <br>* ubuntu 18.04, актуальные для этой версии ubuntu пакеты redis и memcached установленные через apt<br>* YCSB https://github.com/brianfrankcooper/YCSB/releases/download/0.15.0/ycsb-0.15.0.tar.gz <br>Конфиги приведены: <br>для redis - выключен save (не нужно, но пусть)<br>для memcached - 20 тредов, 30GiB и -M<br><br>Процессоры AMD EPYC 7501, память 2666 ECC<br>lxc (nproc 110, 200G) контейнер для redis и memcached<br>lxc (nproc 64, 100G) контейнер для ycsb <br><br>Итог: redis в 9 раз медленнее throughput, в 10 раз медленнее latency и в 1,4 раза прожорливее, чем memcached.<br>------------------------------------------------------------------------------------------------------------------------------------------<br><br>Любой может повторить в три притопа, три прихлопа.<br><br>Ты можешь конечно начать лечить, что в redis можно применять pipeline, но только обычно это не применимо для типичных кейсов кеширования и всё равно он будет медлен https://opennet.me/openforum/vsluhforumID3/118500.html#29 Sun, 22 Sep 2019 14:12:42 GMT &gt; Узлы в кластере не обязаны быть связаны<br><br>тогда это не кластер, а просто набор несвязанных сервисов. <br>А вопросы задержек, синхронизации и фэйловера надо задавать уже тому, кто за них это делает.<br><br>&gt; И до лампочки что там у facebook<br><br>ну так и что там у тебя - до лампочки, потому что непонятно ни как это настроено, ни как используется. Какой-то синтетический тест? А какое он имеет отношение к (моим, к примеру) реальным применениям?<br><br>вообще - результаты странные. Если бы меня интересовали результаты такого теста - надо было бы лезть разбираться, что не так в тесте или в мемкэше.<br><br><br><br><br>