memcached php что такое
Memcached php что такое
Пример #1 Пример использования модуля memcache
В этом примере происходит сохранение объекта в кеше и его последующее чтение. Объекты и другие нескалярные типы сериализируются перед сохранением, что делает невозможным хранение ресурсов (например, идентификаторов подключений и др.) в кеше.
Пример #2 Использование memcache в качестве обработчика сессий
User Contributed Notes 3 notes
memcached is great, is lightning fast, very versatile and useful, scalable, and is a must have for many projects
but if you only want speed to minimize session file blocking there is also a good alternative, tmpfs
maybe if you are in debian you already had session directory in tmp (mounted as tmpfs), but beware of daily cleaning process that can mess up your sessions
you can use this trick if you are in centos/other (like me) or even if you are in debian but want to get ride of /tmp cleaning task
i realized in my system /run is also mounted as tmpfs, so i shut php-fpm down, moved my php session dir to /tmp/, reconfigure php and start again. (you can adapt it to your situation)
the only drawback is tmpfs is VOLATILE, just like memcached (data is lost on unmount/shutdown/power fail), to circumvent this risk i wrote another service that restores/backup php session dir before/after php starts/stops. (UNTESTED!)
vim /etc/systemd/system/php-session-backup.service
——
# basic persistence for tmpfs php sessions
[Unit]
Description=PHP tmpfs sessions backup/restore on shutdown/boot
Before=php-fpm.service
[Install]
WantedBy=multi-user.target
——
systemctl enable php-session-backup
you can also complement this with a daily backup task in case of system crash so you will lose just one day
this is very rough though, you can better use inotify + rsync, could take some ideas from here
Memcached и PHP ликбез
Что такое Memcache и какое отношение он имеет к PHP?
Memcache разработан для кэширования данных, генерация которых требует большого количества ресурсов. Такого рода данные могут содержать что угодно, начиная с результатов запроса к базе данных и заканчивая тяжеловесным куском шаблона. Memcached не входит в базовый набор модулей, поставляемых с PHP, однако он доступен в репозитории pecl.
Установка и настройка
В качестве рассматриваемого дистрибутива я решил использовать Debian, потому как он наиболее часто используется при создании web-серверов. Модуль Memcached для PHP доступен в репозитории уже скомпилированным (php5-memcached), но я опишу процесс установки из исходного кода, так как не все репозитории настолько богаты, как дебиановский.
Устанавливаем сервер Memcached
#/etc/memcached.conf
#Memcached будет работать, как демон
-d
#Лог будет складывать туда
logfile / var / log / memcached.log
#Отведём 256 мегабайт ОЗУ под хранилище
-m 256
#Слушать будет этот порт
-p 11211
#В последствии желательно поменять
-u nobody
#Слушаем localhost
-l 127.0.0.1
Проверяем
Компилируем и устанавливаем модуль для PHP
apt-get install php5-dev libmemcache-dev
echo ‘extension=memcache.so’ >> / etc / php5 / apache2 / php.ini
/ etc / init.d / apache2 restart
Примеры использования
1. Базовые операции
В результате выполнения этого кода каждый раз будет выводиться время с точностью до секунд. Однако обновляться оно будет раз в 5 секунд, пока не очистится кэш. В данном примере проиллюстрированы самые простые операции, но в производительности мы скорее потеряем, чем выиграем. Ведь нам каждый раз придётся подключаться к серверу…
2. Повышаем производительность
2.1 С кэшированием
В данном примере приведена функция, которая создаёт изображение размером 800×600 и расставляет на нём 10 000 точек. Один раз, сгенерировав такое изображение, в дальнейшем мы лишь выводим его на экран, не генерируя заново.
2.2 Без кэширования
Тут всё гораздо проще и привычней: генерируем изображение каждый раз заново.
Результаты
Я протестировал оба скрипта на производительность. Одна и та же машина в первом случае выдала 460 ответов в секунду, а во втором лишь 10. Чего и следовало ожидать. 
Ещё несколько полезных функций
addServer — в случае, если у вас в распоряжении несколько кэширующих серверов, вы можете создать некий кластер, добавляя сервера в пул. Следует обратить внимание на параметр weight. Он указывает на то, сколько памяти вам будет доступно на конкретном сервере.
delete — из названия понятно, что данный метод удаляет из кэша объект с заданным ключом.
replace — заменяет значение объекта с заданным ключом. Используйте в случае, если Вам понадобится изменить содержимое объекта, раньше чем истечёт время его жизни.
С моей точки зрения, применять кэширование стоит только на высоконагруженных ресурсах. Ведь каждый раз, подключаясь к серверу Memcached, вы тратите драгоценное время, что скорее всего не будет оправданным. Что касается больших проектов, лучше сразу написать больше строк кода, чем потом делать это в попыхах, с мыслью о том, что ваш сервис лежит. Также не стоит забывать о расходовании памяти! Учтите, что положив 300 мегабайт в кэш, вы отняли у себя 300 мегабайт ОЗУ.
В завершение хочу сказать, что данная статья не раскрывает все прелести технологии, однако я надеюсь, что она стимулирует Вас к самосовершенствованию. Спасибо за прочтение, многоуважаемый %username%!
UPD: Ещё один интересный момент. Memcached, есть PHP API к libmemcached. А Memcache, библиотека для php, не использующая libmemcached.
Memcache
User Contributed Notes 5 notes
Note that the Memcache 3.0.8 module DOES NOT WORK WITH PHP 7 (or higher)
If you are writing a NEW tool, and you want to use Memcache, use the MemcacheD library. If you are trying to repair an old tool, you’ll either have to stick with PHP 5.6, or, spend the time reworking your code to use MemcacheD.
For example, If you write an object or an array with memcache, it’s interpreted as an integer by memcached. If you write it with memcached, it’s interpreted as a string by memcache.
Thanks to nono303 on GitHub we can run this PHP extension and memcached on Windows! This is great for a dev environment to match a production unix server. I am using PHP 8.0 with this memcache extension on a Windows 10 box with a memcached server running on localhost and it is working great.
I can’t post a link but the dll for this extension is at the repo: nono303/PHP-memcache-dll
And the actual memcached server for windows is at the repo: nono303/memcached
3.0.8 is not really compatible with PHP 7, but this fork seems to be working:
https://github.com/websupport-sk/pecl-memcache
For new projects, memcacheD sounds safer, but this fork might help to keep alive some legacy projects.
I ran Gabriel’s test above and had different results. I did find differences in the objects. For instance:
‘val’ => string(7) «4542.32»
‘valD’ => double(4542.32)
But, I think this could be resolved. Fairly easily.
The main issue with the test was that one port is used. I ran another instance of memcached on a different port and changed the code slightly. I used this code and had better success:
$servers = array(array(‘localserv’, 11212));
$memcache = new Memcache;
$memcacheD = new Memcached;
$memcache->addServer(‘localserv’, 11211);
$memcacheD->addServers($servers);
$memcacheD->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
Кэширование и memcached
Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.
Введение
Для начала, о названии серии постов: посты будут и о кэшировании в Web’е (в высоконагруженных Web-проектах), и о применении memcached для кэширования, и о других применениях memcached в Web-проектах. То есть все три составляющие названия в различных комбинациях будут освещены в этой серии постов.
Кэширование сегодня является неотъемлемой частью любого Web-проекта, не обязательно высоконагруженного. Для каждого ресурса критичной для пользователя является такая характеристика, как время отклика сервера. Увеличение времени отклика сервера приводит к оттоку посетителей. Следовательно, необходимо минимизировать время отклика: для этого необходимо уменьшать время, требуемое на формирование ответа пользователю, а ответ пользователю требует получить данные из каких-то внешних ресурсов (backend). Этими ресурсами могут быть как базы данных, так и любые другие относительно медленные источники данных (например, удаленный файловый сервер, на котором мы уточняем количество свободного места). Для генерации одной страницы достаточно сложного ресурса нам может потребоваться совершить десятки подобных обращений. Многие из них будут быстрыми: 20 мс и меньше, однако всегда существует некоторое небольшое количество запросов, время вычисления которых может исчисляться секундами или минутами (даже в самой оптимизированной системе один могут быть, хотя их количество должно быть минимально). Если сложить всё то время, которое мы затратим на ожидание результатов запросов (если же мы будем выполнять запросы параллельно, то возьмем время вычисления самого долгого запроса), мы получим неудовлетворительное время отклика.
Решением этой задачи является кэширование: мы помещаем результат вычислений в некоторое хранилище (например, memcached), которое обладает отличными характеристиками по времени доступа к информации. Теперь вместо обращений к медленным, сложным и тяжелым backend’ам нам достаточно выполнить запрос к быстрому кэшу.
Memcached и кэширование
Принцип локальности
Кэш или подход кэширования мы встречаем повсюду в электронных устройствах, архитектуре программного обеспечения: кэш ЦП (первого и второго уровня), буферы жесткого диска, кэш операционной системы, буфер в автомагнитоле. Чем же определяется такой успех кэширования? Ответ лежит в принципе локальности: программе, устройству свойственно в определенный промежуток времени работать с некоторым подмножеством данных из общего набора. В случае оперативной памяти это означает, что если программа работает с данными, находящимися по адресу 100, то с большей степенью вероятности следующее обращение будет по адресу 101, 102 и т.п., а не по адресу 10000, например. То же самое с жестким диском: его буфер наполняется данными из областей, соседних по отношению к последним прочитанным секторам, если бы наши программы работали в один момент времени не с некоторым относительно небольшим набором файлов, а со всем содержимым жесткого диска, буферы были бы бессмысленны. Буфер автомагнитолы совершает упреждающее чтение с диска следующих минут музыки, потому что мы, скорее всего, будем слушать музыкальный файл последовательно, чем перескакивать по набору музыки и т.п.
В случае web-проектов успех кэширования определяется тем, что на сайте есть всегда наиболее популярные страницы, некоторые данные используются на всех или почти на всех страницах, то есть существуют некоторые выборки, которые оказываются затребованы гораздо чаще других. Мы заменяем несколько обращений к backend’у на одно обращения для построения кэша, а затем все последующие обращения будет делать через быстро работающий кэш.
Кэш всегда лучше, чем исходный источник данных: кэш ЦП на порядки быстрее оперативной памяти, однако мы не можем сделать оперативную память такой же быстрой, как кэш – это экономически неэффективно и технически сложно. Буфер жесткого диска удовлетворяет запросы за данными на порядки быстрее самого жесткого диска, однако буфер не обладает свойством запоминать данные при отключении питания – в этом смысле он хуже самого устройства. Аналогичная ситуация и с кэшированием в Web’е: кэш быстрее и эффективнее, чем backend, однако он обычно в случае перезапуска или падения сервера не может сохранить данные, а также не обладает логикой по вычислению каких-либо результатов: он умеет возвращать лишь то, что мы ранее в него положили.
Memcached
Memcached представляет собой огромную хэш-таблицу в оперативной памяти, доступную по сетевому протоколу. Он обеспечивает сервис по хранению значений, ассоциированных с ключами. Доступ к хэшу мы получаем через простой сетевой протокол, клиентом может выступать программа, написанная на произвольном языке программирования (существуют клиенты для C/C++, PHP, Perl, Java и т.п.).
Самые простые операции – получить значение указанного ключа (get), установить значение ключа (set) и удалить ключ (del). Для реализации цепочки атомарных операций (при условии конкурентного доступа к memcached со стороны параллельных процессов) используются дополнительные операции: инкремент/декремент значения ключа (incr/decr), дописать данные к значению ключа в начало или в конец (append/prepend), атомарная связка получения/установки значения (gets/cas) и другие.
Memcached был реализован Брэдом Фитцпатриком (Brad Fitzpatrick) в рамках работы над проектом ЖЖ (LiveJournal). Он использовался для разгрузки базы данных от запросов при отдаче контента страниц. Сегодня memcached нашел своё применение в ядре многих крупных проектов, например, Wikipedia, YouTube, Facebook и другие.
Общая схема кэширования
В общем случае схема кэширования выглядит следующим образом: frontend’у (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backend’у, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша.
Такая стандартная схема кэширования реализуется всегда. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.) Однако, как будет показано далее, в высоконагруженном проекте данная схема может работать не самым эффективным образом. Тем не менее, в нашем дальнейшем рассказе мы будем опираться именно на эту схему.
Архитектура memcached
Каким же образом устроен memcached? Как ему удаётся работать настолько быстро, что даже десятки запросов к memcached, необходимых для обработки одной страницы сайта, не приводят к существенной задержке. При этом memcached крайне нетребователен к вычислительным ресурсам: на нагруженной инсталляции процессорное время, использованное им, редко превышает 10%.
Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность O(1), т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Это означает, что некоторые операции (или возможности) будут отсутствовать в нём, если их реализация требует всего лишь линейного (O(n)) времени. Так, в memcached отсутствуют возможность объединения ключей «в папки», т.е. какой-либо группировки ключей, также мы не найдем групповых операций над ключами или их значениями.
Основными оптимизированными операциями является выделение/освобождение блоков памяти под хранение ключей, определение политики самых неиспользуемых ключей (LRU) для очистки кэша при нехватке памяти. Поиск ключей происходит через хэширование, поэтому имеет сложность O(1).
Используется асинхронный ввод-вывод, не используются нити, что обеспечивает дополнительный прирост производительности и меньшие требования к ресурсам. На самом деле memcached может использовать нити, но это необходимо лишь для использования всех доступных на сервере ядер или процессоров в случае слишком большой нагрузки – на каждое соединение нить не создается в любом случае.
По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontend’а до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектов для решения различных задач, в том числе и для кэширования данных.
Потеря ключей
Memcached не является надежным хранилищем – возможна ситуация, когда ключ будет удален из кэша раньше окончания его срока жизни. Архитектура проекта должна быть готова к такой ситуации и должна гибко реагировать на потерю ключей. Можно выделить три основных причины потери ключей:
Все описанные ситуации необходимо иметь в виду при разработке программного обеспечения, работающего с memcached. Можно разделить данные, которые мы храним в memcached, по степени критичности их потери.
«Можно потерять». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД.
«Не хотелось бы потерять». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано новое значение.
«Совсем не должны терять». Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.
Настройка и использование Memcached
В статье мы расскажем, что такое Memcache, зачем он нужен и как он влияет на работу некоторых популярных CMS.
Мы решили исправить этот недостаток, используя технологию контейнеров Docker, нами был создан специальный сервис «memcache». Теперь каждый может установить свой личный memcached, в котором будут гарантированно только Ваши данные.
Подключить персональный memcached возможно в Панели управления, в разделе Сервисы.
Для многих систем управления сайтом (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.
Затем необходимо нажать «Сохранить настройки» (кнопка внизу страницы), в верхней части страницы должно появится сообщение о том, что настройки сохранены и плагин успешно работает с memcached:
Также стоит отметить, что в настройках плагина (вкладка «Backend settings») есть возможность указать логин/пароль для подключения к memcached:
указывать их не нужно, так как доступ к memcached возможен только с вашего аккаунта.
в конфигурационный файл CMS wp-config.php (находится в корневой директории сайта), о чем нам напоминает сам плагин:
Отредактировать wp-config.php можно как через консоль ssh, например через утилиту PuTTy, так и через Файловый менеджер, который встроен в Панель управления хостингом:
На этом настройку можно закончить, сайт будет использовать систему кеширования memcached.
Скорректировать настройки кеширования при необходимости можно в настройках плагина, например, время «жизни» кеша для определенных элементов сайта:
Ключ для кеширования:
На вкладке «Cache exceptions» можно настроить различные исключения для кеширования, такие как:
Результат с включенным memcached:
Как видно, кеширование уменьшило время ответа сервера в 4 раза.
Joomla и memcache
В CMS Joomla! система кеширования (memcached) уже присутствует, её нужно лишь включить. Для это необходимо зайти в панель управления сайтом (по умолчанию: http://site.ru/administrator/), затем перейти в раздел Сайт->Общие настройки:
Выбрать пункт «Система«:
В правой части страницы будет находиться раздел с настройками кеширования, параметры должны быть установлены следующим образом:
Нажать кнопку «Сохранить» в верхней части страницы.
Готово, сайт настроен для работы с memcached.
Проведем замер производительности, без использования memcached:
С использованием memcached:
Хоть разница показателей и незначительна, но с увеличением количества контента на сайте и его посещаемости эта разница будет увеличиваться.
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 отсутствует, то его необходимо создать.
Версию ядра можно посмотреть в разделе администрирования сайта, по умолчанию это ссылка:
http://site.ru/bitrix/admin/index.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.