Сочетание методов кэширования - memcache/disk based

Question

Вот сделка. Мы бы взяли полную статическую html-дорогу для решения проблем с производительностью, но поскольку сайт будет частично динамичным, это не сработает для нас. Вместо этого мы использовали memcache + eAccelerator для ускорения работы PHP и обеспечения кэширования наиболее используемых данных.

Вот наш два подхода, которые мы думали прямо сейчас:

• Использования кэша памяти на все >> < < основных запросов и оставить его в покое, чтобы делать то, что он делает лучше всего.

• Usinc memcache для наиболее часто извлекаемых данных и сочетается со стандартным кэшем, хранящимся в жестком диске, для дальнейшего использования.

Основным преимуществом использования memcache является, конечно же, производительность, но по мере увеличения количества пользователей использование памяти становится тяжелым. Сочетание двух звуков похоже на более естественный подход к нам, хотя теоретический компромисс в производительности. Возможно, у Memcached есть некоторые функции репликации, которые могут пригодиться, когда пришло время для увеличения узлов.

Какой подход мы должны использовать? - Это глупо компрометировать и объединить два метода? Следует ли нам сосредоточиться на использовании memcache и вместо этого сосредоточиться на обновлении памяти при увеличении нагрузки с количеством пользователей?

Большое спасибо!

Answer 1

Компромисс и сочетание этого двух методов - очень умный способ, я думаю.

Наиболее очевидным правилом управления кэшем является латентность v.s. правило размера, которое также используется в кэше CPU. В многоуровневых кэшах каждый следующий уровень должен иметь больший размер для компенсации более высокой задержки. Мы имеем более высокую задержку, но более высокий коэффициент попадания в кеш. Поэтому я не рекомендовал размещать дисковый кэш перед memcache. Сразу же это должно быть место за memcache. Единственным исключением является кеширование каталога, установленного в памяти (tmpfs). В этом случае кеш-файл может компенсировать высокую нагрузку на memcache, а также может иметь латентную прибыль (из-за локальности данных).

Это два хранилища (на основе файлов, memcache) - это не только хранилища, которые удобны для кеша. Вы также можете использовать почти любую базу данных KV, поскольку они очень хорошо контролируют параллелизм.

Кэш-аннулирование - это отдельный вопрос, который может привлечь ваше внимание. Есть несколько трюков, которые вы могли бы использовать, чтобы обеспечить более тонкое обновление кеша при пропуске кеша. Один из них - предсказание эффекта кучи собаки. Если несколько одновременных потоков одновременно пропустили кеш-память, все они переходят в бэкэнд (базу данных). Приложение должно разрешить только одному из них, и остальные из них должны ждать в кеше. Во-вторых, обновление фонового кэша. Приятно обновлять кеш не в потоке веб-запросов, а в фоновом режиме. В фоновом режиме вы можете более эффективно контролировать уровень параллелизма и время ожидания обновления.

На самом деле существует один классный метод, который позволяет выполнять отслеживание кеша на основе тегов (например, memcached-tag). Это очень просто под капотом. С каждой записью кэша вы сохраняете вектор тегов, к которым он принадлежит (например: {directory#5: 1, user#8: 2}). Когда вы читаете строку кеша, вы также читаете все фактические векторные числа из memcached (это может быть эффективно выполнено с помощью multiget). Если хотя бы одна версия фактического тега больше версии тега, сохраненной в строке кэша, то кеш недействителен. И когда вы меняете объекты (например, каталог), соответствующая версия тега должна быть увеличена. Это очень простой и мощный метод, но у него есть свои недостатки. В этой схеме вы не смогли выполнить эффективную недействительность кэша. Memcached может легко отбросить живые записи и сохранить старые записи.

И, конечно же, вы должны помнить: «В информатике есть только две тяжелые вещи: кэш-недействительность и именование вещей» - Фил Карлтон.

Answer 2

Я предлагаю вам сначала использовать memcache для всех основных запросов. Затем попробуйте найти наименее используемые запросы или данные, которые редко меняются, а затем предоставляют кэш для этого.

Если вы можете изолировать общие данные от редко используемых данных, то вы можете сосредоточиться на повышении производительности на наиболее часто используемых данных.

Answer 3

Вы можете делегировать комбинацию кеша диска/памяти в ОС (если ваша ОС достаточно умна). Для Solaris вы даже можете добавить слой SSD посередине; эта технология называется L2ARC.

Я бы рекомендовал вам прочитать это для начала: http://blogs.oracle.com/brendan/entry/test.

Answer 4

Memcached - довольно масштабируемая система. Например, вы можете реплицировать кеш, чтобы уменьшить время доступа для определенных кодов ключей или реализовать алгоритм Ketama, который позволяет добавлять/удалять экземпляры Memcached из пула без переназначения всех ключей. Таким образом, вы можете легко добавить новые машины, предназначенные для Memcached, когда у вас будет дополнительная память. Кроме того, поскольку его экземпляр можно запускать с разными размерами, вы можете вытащить один экземпляр, добавив больше ОЗУ на старую машину. Как правило, этот подход более экономичен и в некоторой степени не уступает первому, особенно для multiget() запросов. Что касается снижения производительности при росте данных, время выполнения алгоритмов, используемых в Memcached, не зависит от размера данных, и поэтому время доступа зависит только от количества одновременных запросов. Наконец, если вы хотите настроить приоритеты памяти/производительности, вы можете установить время истечения срока действия и доступные значения конфигурации памяти, которые будут ограничивать использование ОЗУ или увеличивать количество кешей.

В то же время, когда вы используете жесткий диск, файловая система может стать узким местом вашего приложения. Помимо общей задержки ввода-вывода, такие вещи, как фрагментация и огромные каталоги, могут заметно повлиять на общую скорость запросов. Кроме того, остерегайтесь того, что стандартные настройки жесткого диска Linux настроены больше на совместимость, чем на скорость, поэтому рекомендуется правильно настроить его перед использованием (например, вы можете попробовать hdparm).

Таким образом, перед добавлением еще одной точки интеграции, я думаю, вы должны настроить существующую систему. Обычно правильно созданная база данных, настроенный PHP, Memcached и обработка статических данных должны быть достаточными даже для высокопроизводительного веб-сайта.

Answer 5

Memcached - это то, что вы используете, когда уверены, что вам нужно. Вы не беспокоитесь о том, что он тяжелый в памяти, потому что, когда вы его оцениваете, вы включаете стоимость , выделенных, которые вы собираетесь развернуть.

В большинстве случаев помещение memcached на общей машине является пустой тратой времени, так как ее память будет лучше использовать кеширование, чем бы она ни занималась.

Преимущество memcached заключается в том, что вы можете использовать его как общий кэш между многими машинами, что увеличивает скорость атаки.Более того, вы можете иметь размер кеша и производительность выше, чем может предоставить один ящик, как вы можете (и обычно) развернуть несколько ящиков (по географическому положению).

Также, как обычно используется memcached, зависит от ссылки с низкой задержкой от серверов приложений; так что вы обычно не использовать один и тот же Memcached кластер в различных географических точках в пределах инфраструктуры (каждый DC будет иметь свой собственный кластер)

Процесс:

1. Выявление проблем с производительностью
2. Решите, сколько улучшения производительности достаточно
3. Воспроизведение проблем в тестовой лаборатории на оборудовании серийного производства с необходимыми машинами для драйверов - это нетривиально, и вам может понадобиться много специализированного (даже специализированного) оборудования для жесткого приложения вашего приложения.
4. Протестируйте предлагаемое решение
5. Если это работает, отпустите его на производство, если нет, попробуйте больше параметров и начните снова.

Вы не должны

• Cache "все"
• Делайте вещи без измерения их фактического воздействия.

Поскольку ваша среда тестирования производительности никогда не будет идеальной, у вас должно быть достаточно инструментов/мониторинга, чтобы вы могли измерять производительность и профиль вашего приложения IN PRODUCTION.

Это также означает, что каждая вещь, к которой у вас есть кеш, должна иметь счетчик хитов/пропусков кеша. Вы можете использовать это, чтобы определить, когда кеш будет потрачен впустую. Если кэш имеет низкий коэффициент попадания (< 90%, скажем), то это, вероятно, не стоит.

Возможно, также стоит использовать отдельные кешируемые в производстве.

Помните: ОПТИМИЗАЦИИ ПРЕДСТАВЛЯТЬ ФУНКЦИОНАЛЬНЫЕ ОШИБКИ. Сделайте как можно меньше оптимизаций и убедитесь, что они необходимы и эффективны.