Comments 22
Есть ли какие-то встроенные средства понимания частоты использования данных в кэше, чтобы понять, какие редко используются и в случае переполнения их очищать?
Если речь все еще идет о Redis, то конечно есть. maxmemory-policy allkeys-lru
LeastRecentlyUsed — наименее часто используемые
В ответе на этот вопрос:
А насколько в среднем быстрее получается memcached? 10%, 20%, 50%?
Ответ вообще не понятен, везде утверждает что memcache быстрее, а тут говорит что скорости сопоставимы.
на самом деле memcache быстре, но в реальных условиях — это ничтожно малое ускорение, не стоящее того, чтобы отказаться от повсеметсного использования redis
Быстрее в каком случае?
При массовом сохранении/выборке N ключей из того же HASH, Redis будет быстрее за счёт того, что делается 1 запрос, вместо N.
Не говоря уже о том, что в статье ни слова нет про zipmap/ziplist (а общее впечатление от опуса я оставлю при себе)
мемкеш быстрее в случае классического кеша типа "вытащи мне вот по этому ключу" и то, это было некоторое время назад. я давно решил для себя, что я просто везде использую редис, так как даже если преимущество мемкеша есть, — оно ничтожно мало и никак не перекрывает выгоды от редиса
свое общее впечатление я положу рядом с вашим, я уверен, они подружатся
А так, со стороны, кажется что ДЛЯ НИХ memcached лишний.
Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++.
Выступление может и лучшее (ну, допустим докладчик там жонглировал на сцене по ходу доклада), но вот содержание хромает и, как мне кажется, не тянет на конференцию с таким громким названием.
По сути это неполный пересказ документации о memcache, redis и, особенно RabbitMQ без каких-то интересных кейсов или неочевидных особенностей.
Надеюсь организаторы изменят политику по отбору докладов (я был на вашей конференции год назад), и будет больше хардкора.
Это действительно по мнению _участников_ один из лучших докладов 2014-го года. Но если вам хочется чего-то похардкорнее, то у нас для вас ещё 9-ть потоков с докладами, проходящими параллельно :)
Чтобы в этом ориентироваться мы ввели в этом году метку «Для новичков/ средний / для экспертов».
а с rabbit мне как администратору больше всего головной боли доставляет неаккуратность разработчиков — то очередь создадут да забудут (в результате очередь раздувается и ест память), то типы неверные (в результате при падении одной ноды, приложение перестало работать), то ключи для шовелов не согласовали между командами (ищем все вместе почему не доходят события).
условно падал один раз — одна нода в кластере перестала создавать новые очереди, хотя уже подключенные консьюмеры работали. Что за фокус так и не нашли. На случай повторения написали скрипт, который подключается->создает очередь->отправляет сообщение->получает->отключается->отчитывается в zabbix.
Libmemcached имеет больше возможностей реализовывать данные, по умолчанию стерилизуют их при помощи PHP, но можно определить стерилизатор JSON, например.
Я гляжу, к кованию контента на хабре теперь причастны люди, которые даже на слух термины не разбирают.
Использование memcached и Redis в высоконагруженных проектах