memcached и производительность
Я мог бы задавать очень простой вопрос, но не мог найти четкого ответа, прибегая к помощи гугл, поэтому разместил его здесь.
Memcached кэширует информацию в отдельном процессе. Таким образом, для получения кэшированной информации требуется межпроцессное взаимодействие (обычно это сериализация в Java). Это означает, что, как правило, для извлечения кэшированного объекта нам необходимо получить сериализованный объект и, как правило, передать его в сеть.
И сериализация, и сетевая связь являются дорогостоящими операциями. если memcached необходимо использовать оба из них (вообще говоря, могут быть случаи, когда сетевое взаимодействие не требуется), то как быстро Memcached? Разве репликация не является лучшим решением?
Или это компромисс между распределением / независимостью / масштабируемостью платформы от производительности?
3 ответа
Вы правы, что поиск чего-либо в общем кеше (например, memcached) происходит медленнее, чем поиск в локальном кеше (что, я думаю, вы подразумеваете под "репликацией").
Однако преимущество общего кэша состоит в том, что он является общим, что означает, что каждый пользователь кэша имеет доступ к большему количеству кэша, чем если бы память использовалась для локального кэша.
Рассмотрим приложение с базой данных 50 ГБ и десятью серверами приложений, каждый из которых выделяет 1 ГБ памяти для кэширования. Если бы вы использовали локальные кэши, то на каждой машине было бы 1 ГБ кэша, что равно 2% от общего размера базы данных. Если вы использовали общий кеш, то у вас есть 10 ГБ кеша, что составляет 20% от общего размера базы данных. Хиты кеша будут несколько быстрее с локальными кешами, но частота кеша будет намного выше с общим кешем. Поскольку промахи в кеш-памяти астрономически дороже, чем попадания в кеш, несколько медленнее - это цена, которую стоит заплатить, чтобы уменьшить количество промахов.
Теперь точный компромисс зависит от точного соотношения стоимости локального попадания, общего попадания и пропуска, а также от распределения доступа по базе данных. Например, если бы все обращения осуществлялись с набором "горячих" записей размером менее 1 ГБ, то локальные кэши обеспечили бы 100% -ную частоту обращений и были бы такими же хорошими, как и общий кэш. Менее экстремальные распределения могут все еще изменить баланс.
На практике оптимальной конфигурацией обычно (IMHO!) Будет иметь небольшой, но очень быстрый локальный кэш для самых горячих данных, а затем больший и более медленный кэш для длинного хвоста. Вы, вероятно, признаете это как форму других иерархий кеша: рассмотрите способ, которым процессоры имеют маленькие, быстрые кеши L1 для каждого ядра, затем более медленные кеши L2/L3, совместно используемые всеми ядрами на одном кристалле, а затем, возможно, еще более медленное отключение. кэши чипов, используемые всеми матрицами в системе (действительно ли какие-либо современные процессоры используют кэши вне чипа?).
Вы пренебрегаете стоимостью дискового ввода-вывода, которая, по вашему мнению, является самой медленной частью любого процесса и является основным драйвером IMO для использования кэширования в памяти, такого как memcached.
Кэши памяти используют оперативную память по сети. Репликация использует как оперативную память, так и постоянную дисковую память для извлечения данных. Их цели очень разные.
Если вы думаете только об использовании Memcached для хранения легко доступных данных, таких как сопоставление 1-1 для записей таблиц:you-re-’ing-a-bad-time:.
С другой стороны, если ваши данные представляют собой полный набор результатов сложного запроса SQL, который может даже переполнять пул памяти SQL (и его необходимо временно записать на диск для извлечения), вы увидите значительное ускорение,
В предыдущем примере упоминается необходимость записи данных на диск для операции чтения - да, это происходит, если набор результатов слишком велик для памяти (представьте CROSS JOIN) это означает, что вы оба читаете и пишете на этот диск (приходит на ум).
Например, в высокооптимизированном приложении, написанном на C, общее время обработки может составлять 1 микросекунд, и вам может понадобиться ждать подключения к сети и / или сериализации / десериализации (маршалинг / демаршалинг) гораздо дольше, чем время выполнения самого приложения. Вот тогда вы тоже начнете чувствовать ограничения кеширования памяти по сети.