Объединение методов кэширования - на основе memcache / disk

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Процесс:

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

Не стоит

• Кеш "всё"
• Делайте вещи, не измеряя их фактическое влияние.

Поскольку ваша среда тестирования производительности никогда не будет идеальной, у вас должно быть достаточно инструментов / мониторинга, чтобы вы могли измерить производительность и профилировать ваше приложение в ПРОИЗВОДСТВЕ.

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

Может также стоить иметь отдельные кэши, которые можно переключать на производстве.

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

Answer 4

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

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

Answer 5

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

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