Memcache как сбросить кэш
Обновлено: 06.07.2024
Memcached — сервер кеширования данных в оперативной памяти. С его помощью можно добиться увеличения скорости работы сайта и снижения нагрузки на сервер.
Для использования Memcached требуется модуль PHP. На наших серверах установлено два таких модуля — Memcache и memcached. Вы можете использовать оба.
Активируйте модуль в Панели управления. Для этого кликните на баланс аккаунта в правом верхнем углу, после чего перейдите в раздел «Дополнительные услуги» и выберите объем памяти. Определить подходящий размер кеша можно опытным путем: воспользуйтесь проверочным скриптом.
В скрипте, который подключается к кеширующему серверу, укажите путь до сокета:
- Для Memcache: unix:///home/login/tmp/memcached.sock
- Для memcached: /home/login/tmp/memcached.sock:0
Сайты на популярных CMS тоже могут работать с Memcached. Рассмотрим процесс настройки для проектов, созданных с помощью Wordpress, Joomla! и 1C-Битрикс.
WordPress
В CMS Wordpress нет встроенных механизмов подключения к кеширующему серверу, поэтому используйте специальный плагин, например, W3 Total Cache.
Настройка плагина зависит от сайта: не существует алгоритма, который подошел бы каждому проекту. В общем случае рекомендуем включить кеширование страниц (Page cache) и запросов к базе данных (Database cache).
После установки плагина в боковом меню появится пункт «Performance». Перейдите в раздел «General Settings» и найдите блок «Page cache». Включите кеширование (Enable) и в выпадающем списке выберите метод — Memcached. Нажмите «Save all settings».
Выполните те же действия в блоке «Database cache».
В блоке «Cache Preload» установите интервал очистки кеша — 86400 секунд (сутки). Сохраните изменения.
Перейдите к блоку «Advanced». В строке «Memcached hostname» укажите путь до сокета memcached и нажмите «Test». Сокет указан корректно, если в результате получено значение «Test passed».
В строке «Maximum lifetime of cache objects» установите время — 21600 секунд (6 часов). Опуститесь в нижнюю часть страницы и нажмите «Save all settings».
Перейдите в раздел «Database cache» и в строке «Memcached hostname» укажите путь до сокета memcached. Сохраните изменения.
Joomla!
CMS Joomla! поддерживает работу с Memcached по умолчанию.
Чтобы включить кеширование, авторизуйтесь в административной части сайта и перейдите в раздел «Система» → «Общие настройки», вкладка «Система».
В блоке «Настройка кэша» укажите параметры, как на скриншоте. В поле «Сервер Memcache(d)» введите путь до сокета:
Сайт настроен для работы с Memcached.
1С-Битрикс
Чтобы подключить к Memcached сайт на CMS 1С-Битрикс, создайте в каталоге
/public_html/bitrix файл .settings_extra.php и добавьте в него инструкции:
В административной части сайта перейдите в раздел «Настройки» → «Производительность» → «Панель производительности», вкладка «Битрикс (оптимально)», и проверьте, указано ли значение «memcache» в пункте «Хранение кеша».
Вернитесь в раздел «Аккаунт» → «Услуги» Панели управления хостинга и перезагрузите Memcache.
Проверка работы Memcached
Проверьте корректность настроек с помощью специального скрипта.
В корневом каталоге сайта создайте файл memcache.php и поместите в него следующий код.
Посмотреть
Значение в графе «Используется памяти» должно быть больше нуля. Если оно близко к максимальному объему памяти, увеличьте размер кеша в Панели управления.
Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3 и 4.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей.
Сегодня мы поговорим о тэгировании кэшей и о возможности сброса сразу группы кэшей в memcached.
Последний, шестой пост, будет посвящен различным техническим вопросам работы с memcached: анализу статистике, отладке и т.п.
Сброс группы кэшей
Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением, иначе пользователь после редактирования может увидеть старую версию объекта, что его, несомненно, смутит. Есть простой вариант ситуации: мы меняем информацию об объекте с ID 35, и сбрасываем кэш выборки этого объекта по параметру На практике же чаще всего один и тот же объект явно или неявно входит в большое количество выборок, а значит и кэшей.
Рассмотрим такой пример: мы написали блогохостинг, в нем большое количество блогов. Когда один из авторов создает новый пост, меняется большое количество выборок: посты на главной странице и всех вторых страницах списка постов (т.к. все посты «сдвинулись» на один), изменилось количество записей в календаре постов, изменилась RSS-ка, и т.п. Конечно, мы могли бы поставить кэшам этих выборок небольшое время жизни, тогда через какое-то время они сбросятся и будут отображать правильную информацию, но слишком короткое время кэширования (5 секунд, например), будет давать низкое соотношение хитов в кэш, увеличивая нагрузку на БД, а более длительное будет создавать у пользователя ощущение, что информация после создания поста не обновилась, а, значит, пост не добавился. В то же время можно заметить, что в рамках блогохостинга если даже мы сбросим все кэши, связанные с данным блогом, это совсем небольшой процент от общей массы кэширования (т.к. блогов очень много). Остался вопрос: как найти и проидентифицировать все кэши данного блога? Какие-то из них мы можем легко построить, для некоторых это становится уже неудобно: например, количество кэшей постраничного списка постов зависит от количества страниц, которое еще необходимо вычислить. Что же делать?
Одно из возможных решений – тэгирование кэшей. Описанный ниже способ тэгирования по своей сути совпадает с описанным Дмитрием Котеровым в его наблах, но был нами разработан независимо. Существуют и другие варианты тэгирования, например, патч memcached-tag на memcached.
Тэг кэша
Итак, мы вводим новое понятие – тэг кэша. Кэш связан с некоторым списком тэгов. Сам по себе тэг – это некоторое имя и связанная с ним версия (число). Версия тэга может только монотонно увеличиваться. Группой кэшей мы будем называть кэши, имеющие один общий тэг. Для того чтобы сбросить группу кэшей, достаточно увеличить версию соответствующего тэга.
На программном уровне мы знаем, что данная выборка должна быть закэширована и что её кэш будет связан с тэгами tag1 и tag2 (данный факт определяется логикой работы нашего приложения). При создании кэша мы записываем в него кроме данных закэшированной выборки еще текущие (на момент создания кэша) версии тэгов tag1 и tag2 . При получении кэша мы считаем его валидным, если не истекло время его жизни, и при этом текущии версии тэгов tag1 и tag2 равны версиям, записанным в кэше. Таким образом, если мы изменяем (увеличиваем) версию тэга tag1 , все кэши, связанные с этим тэгом, которые были построены ранее, перестанут быть валидными (т.к. в них записана меньшая версия тэга tag1 ).
Рассмотрим пример с нашей выборкой, пусть было так:
Затем произошло некоторое событие, и мы решили сбросить все кэши, ассоциированные с тэгом tag2 , т.е. мы увеличили версию тэга: tag2++ . Изменились версии тэгов:
Теперь наш кэш перестал быть валидным, не смотря на то, что его «срок годности» еще не истёк: версия тэга tag2, сохраненная в нем (63) не совпадает с текущей версией (64).
Версии тэгов
Тэги (то есть их версии) имеет смысл хранить там же, где мы храним и наши кэши, то есть в memcached. Для каждого тэга мы создадим ключ с именем, совпадающим с именем тэга, его значением будет версия тэга. Осталось решить, что использовать в качестве версии тэга? Можно было бы использовать просто числа, инкрементируя их при изменении версии тэга, но это может привести к некорректному поведению при условии возможной потери ключей. Пусть версия тэга равнялась единице, мы закэшировали выборку с этим тэгом, записали в кэш значение тэга – единицу. Затем ключ с версией тэга был удален из memcached, а в следующий момент времени мы захотели сбросить выборки, связанные с тэгом, то есть необходимо увеличить версию тэга. Так как мы потеряли значение версии тэга, мы снова поставим единицу, и теперь наш кэш будет считаться валидным, хотя он сбросился (не важно, какое значение выбирать при увеличении версии тэга, если она была потеряна – всегда возможна ситуация, что это же значение использовалось и ранее).
В качестве версии удобнее использовать текущее время (с достаточной точностью, например, до миллисекунд). Тогда увеличение версии тэга будет всегда давать новую, бóльшую версию, даже в случае потери предыдущей версии. Версия тэга формируется на frontend’ах, их системные часы должны быть синхронизованы (без этого не будет работать и другая функциональность, например, корректное вычисление срока годности кэшей с коротким временем жизни), так что проблем с таким выбором способа вычисления версии не должно быть
Использование такой схемы тэгирования увеличивает количество запросов к memcached, т.к.
нам необходимо для каждого кэша получать версии его тэгов. Накладные расходы можно сократить за счет использование multi-get запросов memcached, а также за счет локального кэширования ключей memcached в пределах одного процесса (если один и тот же тэг привязан к нескольким кэшам).
Уже много раз настраивал memcached для работы через unix-сокеты. И каждый раз на это уходит куча времени, потому что все инструкции в гугле попадаются с одинаковой ошибкой. Даже в документации Bitrix про этот нюанс ничего не сказано. Проблема собственно в правах на сам файлик с сокетом. Поэтому напишу свою статью на эту тему, чисто для себя, чтобы не забыть.
Как настроить memcached через unix-сокеты
Для примера возьмём стандартную CentOS. Установка стандартная:
Далее добавьте memcached в автозагрузку.
Установите библиотеку php-memcache (в 1С-Битрикс: Веб-окружение модуль уже подключён). Если у вас изначально была голая CentOS, то этого модуля скорей всего нет, про это во многих инструкциях забывают:
Далее нужно настроить memcache. В CentOS 6 и 7 версии конфиг находятся в файле /etc/sysconfig/memcached. Выглядеть он должен примерно так:
Самое главное обратите на параметры запуска:
По дефолту права встают 600, но сайты то ходят не с пользователем memcached или bitrix (как пишут во многих инструкциях), поэтому у них просто не хватаеn прав писать в этот сокет. Собственно поэтому выставляем там права 666 или выставляем нужного юзера и тогда всё будет работать.
Как очистить кеш в memcached, когда он работает через сокет?
Очистить memcached кеш в Unix/Linux довольно просто и в гугле находится куча способов, но большинство из них можно использовать, только когда memcache работает через стандартный 11211 порт. А что делать если memcahed настроене на работу через сокеты, как в инструкции в начале статьи? Тогда можно воспользоваться вот такой конструкцией:
Ещё как вариант можно просто перезагрузить сервис (не желательно так делать):
Если утилиты nc нет, она легко ставится из стандартных репозитариев в любом дистрибутиве линукс. В качестве бонуса для тех кто дочитал до конца вот такая команда, которая покажет статистику работы memcahed через сокет:
Очистить кеш в memcached, когда он работает через стандартный порт:
telnet 127.0.0.1 11211 // присоединяемся
flush_all // чистим
quit // разрываем соединение
Настройки memcache для Bitrix сайтов
Для того чтобы в битриксе использовать memcached нужно в файле /bitrix/php_interface/dbconn.php
И в файле /bitrix/.settings_extra.php (если его нет, то создать)
Настройка memcached через unix-сокеты : 1 комментарий
Как ни странно бы это звучало, но в итоге на нескольких крупных проектах я совсем отказался от использования memcached. Так как толку от него на хороших серверах никакого нет. Файловый кеш оказался выгоднее. За счёт кеширования на стороне файловой системы, запрашиваемые файлы будут читаться не с диска, а из этого кеша, т.е. из памяти, как и в случае memcached, и получается что сам memcached совершенно не нужен, а только занимает память.
В каждом конкретном случае нужно смотреть и пробовать, а будет ли вообще хоть какой-то прирост производительности от этого memcached, или стоит переложить всю работу по кешированию на файловую систему.
В битриксе тоже не всё так хорошо и многие компоненты не умеют использовать memcached и вовремя обновлять его кеш, как итог мы видим кучу запросов в гугле как вручную сбростиь кеш в memcached.
В статье мы расскажем, что такое Memcache, зачем он нужен и как он влияет на работу некоторых популярных CMS.
Кеширование данных - немаловажный момент в работе любого веб-проекта. С ростом посещаемости увеличиваются требования к ресурсам сервера, а также увеличивается время генерации страницы. Кеширование, как раз, решает эти проблемы. Распространенным решением является memcached.
Memcached - программное обеспечение, реализующее сервис кэширования данных в оперативной памяти на основе хеш-таблицы. Проще говоря, когда страница сгенерирована, она через memcached помещается в оперативную память, и при последующем обращении к странице незачем её генерировать снова, затрачивая время и ресурсы сервера - она попросту берётся из memcached.
Сама технология memcached не предполагает разделение данных, тем более - разделение доступа. В рамках одного веб-сервера любой пользователь может использовать memcached, в том числе модифицировать и удалять любые данные. Несмотря на то, что в memcached не хранят критичные данные, это может не самым положительным образом сказаться на работе сайта.
Подключить персональный memcached возможно в Панели управления, в разделе Сервисы.
Для установки доступно несколько тарифов:
128 Мб - 1 руб./день
256 Мб - 2 руб./день
1024 Мб - 4 руб./день
Для многих систем управления сайтом (CMS) существуют механизмы работы с memcached. Далее мы рассмотрим настройку memcached для самых популярных CMS и проведем нагрузочное тестирование с целью узнать, как изменится производительность сайта.
Для тестирования производительности сайтов будем использовать утилиту siege.
Для каждой CMS будем проводить тестирование со временем 5 минут.
WordPress и memcache
Для установки плагина работы с memcache, нужно зайти в административную панель сайта (http://site.ru/wp-admin/), затем в выпадающем списке меню "Плагины", выбрать пункт "Добавить новый":
На открывшейся странице в верхней части есть поиск по плагинам, нужно ввести в это поле название плагина WP-FFPC и нажать "Enter":
Затем нажать "Установить":
И активировать плагин:
Готово, плагин установлен, осталось его настроить, для этого нужно зайти в настройки плагина:
Установить тип расширения PHP Memcache (без d) можно для версий PHP 7.2 и ниже. Для версии 7.3 и выше Вы сможете выбрать только PHP Memcahed. Различия между этими двумя расширениями несущественны, оба расширения отвечают за подключение сайта к сервису Memcached.
Также стоит отметить, что в настройках плагина (вкладка "Backend settings") есть возможность указать логин/пароль для подключения к memcached:
указывать их не нужно, так как доступ к memcached возможен только с вашего аккаунта.
Последний штрих - включение кеширования. Сделать это можно путем добавления специальной директивы:
в конфигурационный файл CMS wp-config.php (находится в корневой директории сайта), о чем нам напоминает сам плагин:
Отредактировать wp-config.php можно как через консоль ssh, например через утилиту PuTTy, так и через Файловый менеджер, который встроен в Панель управления хостингом:
На этом настройку можно закончить, сайт будет использовать систему кеширования memcached.
Скорректировать настройки кеширования при необходимости можно в настройках плагина, например, время "жизни" кеша для определенных элементов сайта:
Ключ для кеширования:
По умолчанию это:
На вкладке "Cache exceptions" можно настроить различные исключения для кеширования, такие как:
- кеширование для залогиненных пользователей сайта (по умолчанию выключено);
- кеширование отдельных элементов сайта (Exclude home/Exclude feeds/Exclude archives/Exclude pageg/Exclude singulars) и динамических страниц (Dynamic requests) по умолчанию включено;
- кеширование для страниц, начинающихся с /wp- , по умолчанию выключено.
Проведем тестирование скорости загрузки страниц сайта, с помощью утилиты siege, время для тестирования - 5 минут. Результат при отключенном memcached:
Transactions: 7258 hits - количество опрошенных страниц сайта за 5 минут
Response time: 0.49 secs - среднее время ответа сервера при запросе
Результат с включенным memcached:
Transactions: 11518 hits - количество опрошенных страниц сайта
Response time: 0.12 secs - среднее время ответа сервера
Как видно, кеширование уменьшило время ответа сервера в 4 раза.
Joomla и memcache
Выбрать пункт "Система":
В правой части страницы будет находиться раздел с настройками кеширования, параметры должны быть установлены следующим образом:
- Кеш -> Стандартное кеширование
- Обработчик кэширования -> Memcache
Нажать кнопку "Сохранить" в верхней части страницы.
Готово, сайт настроен для работы с memcached.
Проведем замер производительности, без использования memcached:
С использованием memcached:
Видно уменьшение времени генерации ответа сервером - 0.09 сек. против 0.13 сек.
Хоть разница показателей и незначительна, но с увеличением количества контента на сайте и его посещаемости эта разница будет увеличиваться.
Drupal и memcache
Первым делом нужно подключится к серверу по ssh, например через утилиту PuTTy, затем в консоли ssh-клиента перейти в корневую директорию сайта с drupal'ом:
Полный путь до сайта можно посмотреть в Панели управления, в разделе Сайты:
и выполнить команду:
Плагин установлен, осталось добавить несколько строк настроек в файл конфигурации CMS, по умолчанию этот файл (относительно корня сайта) находится по пути
./sites/default/settings.php
Для его редактирования из консоли можно воспользоваться одним из редакторов файлов, например vim или nano, также файл можно отредактировать из Панели управления, перейдя в раздел Файловый менеджер:
И сохранить его:
Установка плагина завершена, осталось его активировать, для это нужно зайти в административную панель сайта http://site.ru/admin/ перейти в раздел "Модули":
в самом низу страницы отметить чекбоксы для активации плагина и нажать кнопку "Сохранить":
Установка завершена, сайт использует кеширование memcache.
Проведем тест скорости загрузки страниц сайта с помощью siege:
Без использования memcached:
с использование memcached:
Видим прирост производительности на одну треть.
Bitrix и memcache
Для подключения кеширования memcache в CMS Bitrix необходимо отредактировать файл:
./bitrix/php_interface/dbconn.php (если версия ядра меньше 14.0)
./bitrix/.settings_extra.php (если версия ядра выше 14.0). Если файл ./bitrix/.settings_extra.php отсутствует, то его необходимо создать.
Версию ядра можно посмотреть в разделе администрирования сайта, по умолчанию это ссылка:
Отредактировать необходимый файл можно, подключившись к серверу по ssh, используя утилиту PuTTy, или через Файловый менеджер, который встроен в Панель управления хостингом.
Если редактируется файл ./bitrix/php_interface/dbconn.php (версия ядра меньше 14.0), то следует добавить строки:
Если редактируется файл ./bitrix/.settings_extra.php (версия ядра выше 14.0), то следует добавить строки:
Для проверки, что сайт использует memcached, следует перейти в административную панель сайта->настройки->панель производительности->Битрикс:
Хранение кеша должно быть установлено в memcache:
Сравним производительность сайта.
Без использования memcached:
с использование memcached:
Видим, что сервер тратит меньше времени на генерацию страницы:
С увеличением контента и посетителей ресурса разница будет значительнее.
Насколько мы видим, все представленные CMS работают быстрее. При этом тестирование проводилось на CMS «из коробки» (установка производилась из Панели управления, раздел CMS), т.е. без контента, а это означает, что на рабочих и заполненных сайтах увеличение скорости работы будет видно более явно.
Webasyst и memcache
Для использования memcached с Webasyst требуется создать в каталоге сайта файл wa-config/cache.php с следующим содержимым:
Убедиться, что кэширование работает, можно, создав в корне сайта файл с таким кодом:
При обращении к нему будут выведены все ключи данных, хранящихся в Memcached.
Удачной работы! Если возникнут вопросы - напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел "Помощь и поддержка".
Использование memcached для 1С-Битрикс повысит производительность, уменьшит время отклика сервера, а страницы сайта будут загружаться быстрее.
Установка memcached
Если используете 1С-Битрикс: Веб-окружение, то memcached и уже установлен. Его необходимо включить залогинившись в BitrixEnv на сервере выбрав в меню Configure Memcahed service for the pool. Затем переходите к конфигурации memcached.
Если же memcached не установлен или вы используете не стандартное веб-окружение, установите его на сервер. В CentOS это делается так:
Далее добавьте memcached в автозагрузку.
Установите библиотеку php-memcache (в 1С-Битрикс: Веб-окружение модуль уже подключён).
Затем перезагрузите apache.
Конфигурация memcached
Файле /etc/sysconfig/memcached задайте следующие параметры (если нет причин использовать иное):
Примечание: параметры MAXCONN (количество одновременных подключений, по умолчанию 1024), CACHESIZE (объем памяти для кэша, по умолчанию 64MB) подбираются экспериментальным путем в зависимости от характера нагрузки и от имеющихся ресурсов. Оценить объем памяти, необходимой для кэширования (параметр CACHESIZE), можно по размеру вашего файлового кэша. Если на проекте файловый кэш занимает 3 GB, то использование memcached c 256МБ памяти не будет эффективным за счет частого вытеснения.
После настройки memcaсhed перезапустите его:
CentOS 6:
CentOS 7:
Настройка memcached в 1С-Битрикс
Чтобы 1С-Битрикс стал использовать memcached нужно внести изменения в конфигурационные файлы.
В файле /bitrix/php_interface/dbconn.php
И в файле /bitrix/.settings_extra.php (если его нет, то создать)
Вместо файла settings_extra.php секцию с memcache можно добавить в файл /bitrix/.settings.php
или с помощью скрипта
Как очистить кэш memcached
Если понадобится очистить кэш memcached это можно сделать. Самый простой способ — telnet.
Или через netcat.
Ссылки
На этом всё. Но вы можете поддержать проект. Даже небольшая сумма поможет нам писать больше полезных статей.
Если статья помогла или понравилась, пожалуйста поделитесь ей в соцсетях.
Читайте также: