Объединение методов кэша - кэш-память / находящийся на диске
Вот соглашение. Мы взяли бы полную статическую дорогу HTML для решения проблем производительности, но так как сайт будет частично динамичным, это не удастся для нас. О чем мы думали, вместо этого использует кэш-память + eAccelerator, чтобы ускорить PHP и заботиться о кэшировании для наиболее используемых данных.
Вот наши два подхода, о которых мы думали прямо сейчас:
Используя кэш-память на>> все <<главные запросы и оставление в покое его, чтобы сделать то, что это прилагает все усилия.
Кэш-память Usinc для обычно полученных данных, и объединяющийся со стандартом сохраненный жестким диском кэш для дальнейшего использования.
Главным преимуществом только использования кэш-памяти является, конечно, производительность, но как пользовательские увеличения, использование памяти становится тяжелым. Объединение этих двух походит на более естественный подход к нам, даже при том, что теоретический компромисс в производительности. Memcached, кажется, имеет в наличии некоторые функции репликации также, которые могут прибыть удобные, когда пора увеличить узлы.
Какой подход мы должны использовать? - Действительно ли глупо поставить под угрозу и объединить эти два метода? Должны мы insted сфокусироваться на использовании кэш-памяти и вместо этого фокусировке на обновлении памяти, когда загрузка увеличивается с числом пользователей?
Большое спасибо!
5 ответов
Компромисс и объединение этих двух методов - очень умный способ, я думаю.
Наиболее очевидным правилом управления кэшем является правило "латентность против размера", которое используется и в кэше процессора. В многоуровневых кэшах каждый следующий уровень должен иметь больший размер для компенсации более высокой латентности. Мы имеем более высокую латентность, но более высокий коэффициент попадания в кэш. Поэтому я не рекомендую размещать дисковый кэш перед memcache. Наоборот, его следует размещать позади memcache. Единственное исключение - если вы кэшируете каталог, смонтированный в памяти (tmpfs). В этом случае файловый кэш может компенсировать высокую нагрузку на memcache, а также может иметь выигрыш в латентности (из-за локальности данных).
Эти два хранилища (файловое, memcache) - не единственные хранилища, удобные для кэширования. Вы также можете использовать практически любую базу данных KV, поскольку они очень хороши в управлении параллелизмом.
Аннулирование кэша - это отдельный вопрос, который может привлечь ваше внимание. Есть несколько приемов, которые можно использовать для обеспечения более тонкого обновления кэша при его промахах. Один из них - предсказание эффекта собачьей кучи. Если несколько одновременных потоков одновременно получили промахи в кэше, все они отправляются в бэкэнд (базу данных). Приложение должно позволить только одному из них продолжить работу, а остальные должны ждать в кэше. Второе - это фоновое обновление кэша. Хорошо обновлять кэш не в потоке веб-запроса, а в фоновом режиме. В фоновом режиме вы можете контролировать уровень параллелизма и таймауты обновления более изящно.
На самом деле есть один классный метод, который позволяет отслеживать кэш на основе тегов (например, memcached-tag). Он очень прост под капотом. С каждой записью кэша вы сохраняете вектор версий тегов, которым она принадлежит (например: {directory#5: 1, user#8: 2}). При чтении строки кэша вы также читаете все фактические номера векторов из memcached (это может быть эффективно выполнено с помощью multiget). Если хотя бы одна фактическая версия тега больше, чем версия тега, сохраненная в кэш-линии, то кэш аннулируется. А при изменении объектов (например, каталога) соответствующая версия тега должна быть увеличена. Это очень простой и мощный метод, но у него есть и свои недостатки. В этой схеме невозможно выполнить эффективное аннулирование кэша. Memcached может легко отбросить "живые" записи и сохранить старые.
И, конечно, вы должны помнить: "В информатике есть только две трудные вещи: аннулирование кэша и именование вещей" - Фил Карлтон.
Я бы посоветовал вам сначала использовать кэш памяти для всех основных запросов. Затем протестируйте, чтобы найти наименее используемые запросы или данные, которые редко меняются, а затем предоставьте для этого кеш.
Если вы можете изолировать общие данные от редко используемых данных, тогда вы можете сосредоточиться на повышении производительности на более часто используемых данных.
Memcached - это то, что вы используете, когда уверены, что вам это нужно. Вы не беспокоитесь о том, что он будет занимать много памяти, потому что при его оценке вы включаете стоимость выделенных блоков, на которых вы собираетесь его развернуть.
В большинстве случаев размещение memcached на разделяемой машине - пустая трата времени, так как его память лучше использовать для кэширования всего, что он делает.
Преимущество memcached в том, что вы можете использовать его в качестве общего кэша между многими машинами, что увеличивает частоту попаданий. Более того, у вас может быть размер кеша и производительность выше, чем может дать один ящик, так как вы можете (и обычно будете) развернуть несколько ящиков (для каждого географического местоположения).
Также способ, которым обычно используется memcached, зависит от ссылки с низкой задержкой с серверов приложений; поэтому обычно вы не будете использовать один и тот же кластер memcached в разных географических точках вашей инфраструктуры (каждый DC будет иметь свой кластер)
Процесс следующий:
- Выявление проблем с производительностью
- Решите, насколько улучшения производительности достаточно
- Воспроизводите проблемы в своей тестовой лаборатории на оборудовании производственного уровня с необходимыми драйверами - это нетривиально, и вам может потребоваться много выделенного (даже специализированного) оборудования, чтобы работать с вашим приложением достаточно жестко.
- Протестируйте предложенное решение
- Если оно работает, выпустите его в производство, если нет, попробуйте другие варианты и начните заново.
Вы не должны
- Кэшировать «все»
- Делать что-либо, не оценивая их реальное влияние.
Поскольку ваша среда тестирования производительности никогда не будет идеальной, у вас должно быть достаточно инструментов / средств мониторинга, чтобы вы могли измерять производительность и профилировать свое приложение В ПРОИЗВОДСТВЕ.
Это также означает, что каждая вещь, которую вы кешируете, должна иметь счетчик попаданий / промахов в кеш. Вы можете использовать это, чтобы определить, когда кэш тратится впустую. Если кэш имеет низкий процент попаданий (скажем, <90%), то это, вероятно, не имеет смысла.
Также, возможно, стоит переключить отдельные кэши в процессе производства.
Помните: ОПТИМИЗАЦИЯ ВЫВОДИТ ФУНКЦИОНАЛЬНЫЕ ОШИБКИ. Сделайте как можно меньше оптимизаций и убедитесь, что они необходимы И эффективны.
Вы можете делегировать комбинацию кэша диска / памяти ОС (если ваша ОС достаточно умна). Для Solaris вы даже можете добавить слой SSD посередине; эта технология называется L2ARC.
Я рекомендую вам для начала прочитать это: http://blogs.oracle.com/brendan/entry/test .
Memcached - достаточно масштабируемая система. Например, вы можете реплицировать кеш, чтобы уменьшить время доступа для определенных ключевых сегментов, или реализовать алгоритм Ketama, который позволяет вам добавлять / удалять экземпляры Memcached из пула без переназначения всех ключей. Таким образом, вы можете легко добавлять новые машины, выделенные для Memcached, когда у вас есть дополнительная память. Кроме того, поскольку его экземпляр может работать с разными размерами, вы можете создать один экземпляр, добавив больше ОЗУ на старую машину. В целом этот подход более экономичен и в какой-то мере не уступает первому, особенно для запросов multiget () . Что касается падения производительности с ростом данных, время выполнения алгоритмов, используемых в Memcached, не зависит от размера данных, и поэтому время доступа зависит только от количества одновременных запросов. Наконец, если вы хотите настроить приоритеты памяти / производительности, вы можете установить время истечения срока действия и доступные значения конфигурации памяти, которые будут ограничивать использование ОЗУ или увеличивать количество обращений к кешу.
В то же время, когда вы используете жесткий диск, файловая система может стать узким местом вашего приложения. Помимо общей задержки ввода-вывода, такие вещи, как фрагментация и огромные каталоги, могут заметно повлиять на общую скорость вашего запроса. Также помните, что настройки жесткого диска Linux по умолчанию больше настроены на совместимость, чем на скорость, поэтому рекомендуется правильно настроить его перед использованием (например, вы можете попробовать утилиту hdparm ).
Таким образом, прежде чем добавлять еще одну точку интеграции, я думаю, вам следует настроить существующую систему.Обычно правильно спроектированной базы данных, настроенного PHP, Memcached и обработки статических данных должно хватить даже для высоконагруженного веб-сайта.