Технологии кластеризации 1С-Битрикс - эффективное кеширование в memcached

Сегодня хочу рассказать о полезной возможности, которая появилась в 10 версии продукта (редакции "Веб-кластер", "Бизнес веб-кластер" ) - о кластерном кешировании в memcached. Но сначала поговорим ... просто о кешировании.

Для чего используется технология кеширования в платформе 1С-Битрикс

Веб-сайт содержит информацию, которая хранится в надежном хранилище: базе данных. В принципе, можно "ходить" за информацией в базу данных постоянно, при каждом обращении к веб-сайту. И такие веб-сайты существуют в природе

Однако, если наш веб-сайт станет популярным, то, каким бы оптимальным и качественным не был программный код - база данных быстро станет перегруженной и придется наращивать аппаратные мощности сервера базы данных, докупая дорогое топовое оборудование. Это поможет на определенное время, но, если посещаемость ресурса продолжает расти, вы упретесь в "потолок" производительности сервера базы данных и нужно будет срочно в авральном режиме переделывать приложение (например, на выходных или в период летних отпусков ).

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

Именно поэтому при разработке веб-сайта мы рекомендуем как можно раньше начать пользоваться преимуществами технологии кэширования, реализованными в платформе 1С-Битрикс.

Технология работает так:

1) Веб-сайт для получения необходимой информации обращается к базе данных и сохраняет ответ (например получаем список новостей).
2) В следующий раз, если информация не поменялась*, веб-сайт не обращается к базе данных, а отдает клиенту сохраненный ответ.
3) Однако, если информация поменялась, веб-сайт снова обращается к базе данных.

*) Технология, которая проверяет, обновилась информация в или нет, называется технологией управляемого кэширования (Сache Dependencies).

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

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

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



"Быстрокэширование" - известная ловушка

Иногда во время разработки активно используются технологии кэширования, однако при возрастании нагрузки база данных подвергается перегрузкам. Почему? Для предупреждения данного риска необходимо сначала обеспечить наиболее оптимальную работу с базой данных С ВЫКЛЮЧЕННЫМ КЭШИРОВАНИЕМ, прежде чем его включать (рекомендую менеджерам интернет-проектов взять это на заметку и включить в чеклист контроля качества проекта).
Типичный кейс данной "ловушки" такой - при включенном кэшировании кастомизированное меню использует 0 SQL-запросов, при выключенном - 5000!


Эффективное кэширование

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

Допустим, через определенное время, наш веб-сайт стал популярным ресурсом. Благодаря активному использованию технологии кэширования мы надежно защитили базу данных от высокой нагрузки и она может выдержать 3-5 кратное превышение нагрузки.

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

Решение есть - перенести кэш в memcached. Сервер memcached устанавливается системным администратором за считанные минуты и на веб-сайте нужно установить всего лишь одну настройку платформы 1С-Битрикс.

При использовании memcached временные данные будут храниться в оперативной памяти. Можно выделить для хранения кэша недорогой сервер с несколькими гигабайтами памяти.

При этом, устаревшие данные будут автоматически вытесняться и наш кэш перестанет "расползаться" по системе, пожирая все больше и больше места. Допустим, мы выделили в memcached 4GB места для кэширования и можем быть уверенными, что больше 4GB кэш не вырастет, а наименее часто используемые данные будут вытесняться (алгоритм LRU). Очень удобно и эффективно.


Кластеризованный кэш на базе memcached

Для увеличения производительности и отказоустойчивости проекта, мы переходим на редакцию продукта "Веб-кластер" (или "Бизнес веб-кластер" ). Теперь веб-сайт размещен на двух серверах.

Для хранения кэша уже недостаточно одного сервера memcached. Также, для эффективного использования вычислительных ресурсов мы хотим, чтобы созданный кэш на одном сервере веб-кластера использовался на другом сервере веб-кластера.

Для решения этой задачи - используем кластеризованный кэш серверов memcached ("Рабочий стол/Настройки/Веб-кластер/Memcached" ). Мы подключаем к проекту столько кэширующих серверов, сколько нам нужно - никаких ограничений.



Если подключаемые к кластеру memcached сервера разной мощности или с разным объемом оперативной памяти - желательно соответственно настроить коэффициент их использования через настройку параметра "Процент распределения нагрузки (0..100)" (1).




При настройке подсистемы кластерного кэширования обращаем внимание на параметр:

get_hits: #count# (#hitrate#%)

#hitrate# - показывает эффективность кэширования (3) и должен быть как можно ближе к 100%. Экспериментально регулируем эффективность, постепенно увеличивая объем памяти (2), выделяемой серверу memcached (limit_maxbytes). Рекомендую начинать с объема памяти в 128MB и увеличивать с шагом в 32MB, пока #hitrate# перестанет заметно увеличиваться.

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

Также хочу отметить, что при использовании нескольких memcached-серверов увеличивается надежность подсистемы кэширования - в случае отказа одного из memcached-серверов ничего страшного не произойдет, веб-сайт будет эффективно использовать оставшиеся серверы.

В результате кэш нашего веб-проекта будет всегда "в хорошем тонусе"  - небольшой, централизованный и эффективный .

Итоги

1) Мы убедились, что технологии кэширования веб-проекта это не дань моде, а насущная необходимость, обеспечивающая устойчивость веб-сайта к возрастающим нагрузкам за счет максимального снижения загруженности базы данных. И нужно предусмотреть использование этих технологий как на этапе проектирования в ТЗ, так и ранних стадиях разработки.

2) Если вовремя не внедрить в веб-проект технологии кэширования, то скорее всего этим придется заниматься в самое неожиданное время (выходные, летние отпуска) из-за перегрузки базы данных.

3) Мы рассмотрели, как наиболее эффективно использовать технологии кластеризованного кэширования в memcached для повышения отказоустойчивости и производительности веб-проектов на платформе 1С-Битрикс (редакции "Веб-кластер", "Бизнес веб-кластер" ).