Установка и настройка Memcached. Пример программы на PHP Php memcached примеры

Статья для новичков . Memcached – это такая штука для кэширования данных в оперативной памяти сервера.

В чем суть. Сайт обычно берет данные из базы, а база - это большой файл на диске, а чтение с диска априори медленнее чем из памяти. Это начинает проявляться не сразу - как только посещаемость переваливает за несколько десятков тысяч человек, а таблицы в базе вырастают до сотен тысяч строк. Более того, сама база данных по определению не эффективна. Допустим, в базе храним 1 000 000 постов, но за последние несколько дней 95% всех просмотров составляют только 100 постов. Но каждый раз нам приходится лезть в огромный файл базы и искать в нем несколько часто запрашиваемых записей - а это увеличивает нагрузку на сервер и время открытия сайта. Если же мы положим эти записи в кэш, то мы ускорим сайт и не нужно покупать мощные сервера. Одним словом, кэш - это профит !

Кэширование бывает разным. Самое простое - кэширование на файлах . Минус в том, что данные по-прежнему хранятся на диске, а это может привести к печальным последствиям . Можно кэшировать промежуточные результаты в базе (например, результаты поиска в некоторых форумных движках хранятся в базе). Ну и самое эффективное это конечно хранение в оперативной памяти. Для этого существует куча сторонних программ: Memcached, eAccelerator, APC, XCache. Кстати, MySQL тоже умеет хранить данные в своем кэше (речь не об индексах в памяти).

Вообще, пишут, что eAccelerator и XCache эффективней чем Memcached, если вы используете один сервер, так как в случае Memcached необходимо открывать TCP-соединение. Но у Memcached есть главное преимущество - это возможность разнесения данных по нескольким серверам. Например, кэш ЖЖ не уместится в памяти ни одного самого мощного сервера. Собственно, Memcached и был придуман для ЖЖ, чтобы можно было хранить данные на нескольких серверах. Но нам, новичкам, пока рано об этом думать.

Особенности Memcached

Простая структура хранения данных (ключ-значение).
Максимальное время жизни кэша - 30 дней.
Максимальный объем одного элемента - 1 Mb
Можно хранить объекты, массивы как есть. При кэшировании в файлах или в базе подобные вещи нужно загонять в строку при помощи сериализации перед сохранением.
Нет авторизации (пароль-логин). Т.е. если на сервере стоит Memcached, то любой пользователь на этом же сервере может получить к нему доступ.
Скорость доступа к данным не зависит от кол-ва элементов в кэше. Да-да, именно так.

Установка

В сети есть куча инструкций по установке, хоть на Unix, хоть на Windows. Кроме самого Memcached нужно еще поставить либу для обращения к Memcached через PHP (по аналогии с базой MySQL - кроме самой базы нужно еще поставить расширение mysql или mysqli).

Но проще всего написать хостеру. На fastvps при заказе сервера Memcached ставят по умолчанию. Главное, указать сколько памяти нужно выделить под кэш. По умолчанию это 67 Mb. У меня 4 Gb оперативы, то можно смело выделить 1 Gb. Вообще, самый простой способ оценить сколько нужно памяти под кэш, это умножить объем базы на 2. Например, базы на всех наших сайтах весят 300 Мб, то под кэш выделяем 600 Мб, а лучше брать 1 Гб, с запасом.

Memcached можно увидеть в phpinfo

Проверка

Обычно Memcached стоит на localhost и доступен через порт 11211
Смотрим статистику

connect("localhost",11211); print_r($memcache->getStats()); ?>

Результат:
Array
=> 5915
=> 583
=> 1309538445
=> 1.2.2
=> 64
=> 0.000000
=> 0.004000
=> 0
=> 0
=> 0
=> 1
=> 2
=> 2
=> 0
=> 0
=> 0
=> 0
=> 0
=> 7
=> 0
=> 1073741824
=> 1
)

Через какое-то время статистика будет выглядеть примерно так

Array
=> 5915
=> 6202245
=> 1315740107
=> 1.2.2
=> 64
=> 3.464216
=> 10.868679
=> 298
=> 17728
=> 120366
=> 1
=> 28654
=> 4
=> 133296
=> 17728
=> 124758
=> 8538
=> 0
=> 11125692
=> 103815319
=> 1073741824
=> 1
)

Оновные параметры:
=> 298 - сколько текущих элементов в кэше.
=> 17728 - сколько всего было элементов в кэше (в том числе и удаленных)
=> 120366 - сколько байт сейчас лежит в кэше
=>1073741824 - сколько байт вообще доступно под кэш (тут 1 Gb)
=> 124758 - сколько раз мы взяли данные из кэша
=> 8538 - сколько раз мы пытались взять данные из кэша, но его там не было или время жизни кэша истекло.

Отношение get_misses/get_hits показывает эффективность использования кэша. Чем оно меньше, тем эффективней используется кэш. В данном случае у нас получается, что 93% данных берется из кэша. Если у вас get_misses/get_hits=1, то значит вы делаете что-то не так (скорее всего ставите слишком малое время жизни кэша).

визуальная статистика
Код выше выводит статистику в сухом виде типа print_r()
Есть красивый вывод статистики - phpMemcachedAdmin

Это обычный php-скрипт. Открываете его у себя на сайте и получаете красивое оформление.
Настраивать ничего не нужно. По умолчанию он коннектится к localhost:11211
Скачать можно на официальной странице .

Примеры использования Memcache

Допустим, у нас есть строка "test111", мы хотим ее закэшировать на 1 день. Придумаем ей какой-нибудь ключ "key1".

connect("localhost",11211); $memcache->set("key1", "test111", false, 86400); // кэшируем на 1 день. $get_result = $memcache->get("key1"); // получаем данные print_r($get_result); ?>

Усложним немного

get($key)) { $get_result = $memcache->get($key); print_r($get_result); } else { $result = "test222"; // $result – результат каких-то вычислений или выборка из БД $memcache->set($key, $result, false, 86400); echo "записали кэш на 1 сутки"; } ?>

Только со второго запуска этого скрипта мы увидим наши данные.

Еще забыл добавить про время жизни кэша. Memcached имеет ограничение на время жизни - 1 месяц. Так вот, если вы поставите 365 дней, то Memcached просто не сохранит их, при этом не выдаст ни какой ошибки. Поэтому, если ваши данные долго не меняются и вы хотите поставить максимальный срок жизни, то указывайте false
$memcache->set($key, $result, false, false);

Особенность именования ключей. Лучше в качестве ключа брать md5(ключ), потому что максимальная длина ключа 250 символов и нельзя использовать пробелы. А когда вы будет кэшировать SQL-запросы с условием, то ключ будет типа $key = "blog_id_1 WHERE activity=1 AND … AND … LIMIT 10"

Более того, в ключ нужно еще добавить какую-то константу, которая определяет, к какому сайт принадлежит кэш.
$key = md5(PROJECT."key2"); // где константа PROJECT="site.com"

Если этого не сделать, то второй сайт на том же сервере может перезаписать данные первого сайта с тем же ключом. Дело в том, что Memcached не имеет авторизации, как например база данных, поэтому приходится вот таким способом ограничивать доступ. Короче говоря, Memcached - это такая большая свалка пар ключ-значение. Поэтому все сайты хранят кэш в одном Memcached. При этом мы не можем, например, взять 10 последних записанных элементов (типа как в базе LIMIT 10). Структура Memcached необычайна проста, но за счет этого мы получаем высокую производительность.

Тегирование

Так как Memcached чрезвычайно прост (данные никак не связаны между собой - есть только связь ключ-значение), то возникают некоторые трудности на практике. Допустим, у нас есть блоги как на Хабре. Мы написали пост, сохранили его в кэш. Создали несколько пар ключ-значение: кэш под сам пост, кэш для блога, в котором отображается этот пост, кэш для прямого эфира, кэш для вывода постов пользователя в профиле этого пользователя и т.д.

$memcache->set("post_id_2211", "данные");
$memcache->set("post_blog_id_11", "данные");
$memcache->set("live_posts", "данные");
$memcache->set("post_user_id_331", "данные");

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

$memcache->delete("post_id_2211");
$memcache->delete("post_blog_id_11");
$memcache->delete("live_posts");
$memcache->delete("post_user_id_331");
…

Короче, из-за простоты Memcached нам приходится ручками плодить лишний код. Более того, мы должны постоянно помнить какие кэши связаны с другим кэшем. Решение проблемы очень простое. Мы к каждому элементу кэша прикрепляем тег или несколько тегов.
Подробнее можно почитать .

Практика

На практике чистый Memcached никто не использует. Обычно используют какой-то класс-обертку, который поддерживает тегирование. Самым распространенным является решение ZendCache

Скачать одним архивом со всем примерами
Положим класс ZendCache в папку lib

Структура должна быть такой, если смотреть от корня
/lib/DklabCache/...
/class/Cache.class.php
/stat.php
/get_post.php
/update_post.php

Класс-обертка (или как еще называют - врапер (wrapper)) с использованием ZendCache

array(array("host" => MEMCACHED_HOST, "port" => MEMCACHED_PORT, "persistent" => false),), "compression" => false,); self::$instance = new Cache; self::$instance->memcache = new Dklab_Cache_Backend_TagEmuWrapper(new Zend_Cache_Backend_Memcached($aConfigMem)); } else { return NULL; } } return self::$instance; } public function get($key) { return $this->memcache->load($key); } public function set($key, $value, $tags=array(), $timeLife=false) { return $this->memcache->save($value, $key, $tags, $timeLife); } public function delete($key) { $this->memcache->remove($key); } public function clean($cMode = Zend_Cache::CLEANING_MODE_ALL, $tags = array()) { return $this->memcache->clean($cMode,$tags); } public function __construct() { } public function __clone() { } } ?>

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

Константа CACHE_USE прописывается отдельно в конфиге. С помощью нее можно включать/выключать кэширование.

Параметр "compression" => false означает, что мы не сжимаем данные в кэше. Сжатие нужно для экономии места в памяти, но сжатие требует некоторого времени. Поэтому, если для вас не критичен объем памяти, то сжатее отключаем.

Параметр "persistent" => false означает выключение постоянного соединения (по аналогии с mysql_pconnect())

Кстати говоря, тут видно как использовать несколько серверов. Если у нас 1 сервер

"servers" => array(array("host" => "localhost", "port" => 11211, "persistent" => false),)

Например у нас 3 сервера Memcached

"servers" => array(array("host" => "11.33.45.11", "port" => 11211, "persistent" => false), array("host" => "11.33.45.12", "port" => 11211, "persistent" => false), array("host" => "11.33.45.13", "port" => 11211, "persistent" => false),)

По-хорошему, подобные вещи нужно вынести из класса в конфиг.

Теперь подключаем этот класс в скрипт, в котором мы хотим что-то кэшировать
Допустим скрипт вывода поста (в архиве это get_post.php)
Примеры конечно не самые лучшие, но лучше так, чем совсем ничего.
Работу с базой я специально отключил, что бы у вас было меньше проблем.

get($key_cache))){ echo "данные взяли из кэша"; return $data; } else { // находим пост в базе (выполняем select) //$data = $DB->selectRow("SELECT * FROM post WHERE id=?d", $postID); // для упрощения примера беем готовый массив (пост привязан к блогу с ID=3) $data = array("id"=>$postID, "blog_id"=>3, "title"=>"Новость 111", "text"=>"какой-то текст"); if (!empty($data)) { if (isset($Cache)) { $Cache->set($key_cache, $data, array("post_update", "post_update_".$postID, "post_blog_".$data["blog_id"]), 3600*24*10); echo "сохранили данные в кэш"; } return $data; } else return null; } } $postID = 25; $post = get_post($postID); print_r($post); ?> Хотим взять пост с id=25. При первом вызове вы должны увидеть надпись "сохранили данные в кэш". При повторных вызовах вы увидите надпись "данные взяли из кэша". Теперь попробуем обновить пост (запускаем скрипт update_post.php) query("UPDATE post SET blog_id =?d, title=?, text=? WHERE id=?d", $blogID, $title, $text, $postID); // чистим теги, связанные с эим постом $Cache = Cache::getInstance(); if (isset($Cache)) { $Cache->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, array("post_update", "post_update_".$postID, "post_blog_".$blogID)); } return true; } $postID = 25; update_post($postID, 3, "test", "test test"); ?>

После чего запускаем скрипт get_post.php и видим, что данных в кэше не было и мы снова сохранили их туда: "сохранили данные в кэш".

На самом деле самое сложное в кэшировании, это простановка правильных тегов . Чтобы при обновлении поста обновилась данные, в которых лежит этот пост.

На примере выше это были теги

"post_update_".$postID - сам пост (обычно страница вывода поста)
"post_blog_".$blogID - страница блога, где выводится список постов этого блога
"post_update" - тег связанный с главной страницей или списком самых лучших постов

Dog-pile эффект

Переводится как «стая собак». Допустим, у вас есть какая-то сложная выборка из базы на 2 секунды. В кэше ее еще нет (или мы сбросили кэш). Приходит первый пользователь, идет запрос в базу, и только спустя 2 секунды эти данные появятся в кэше. Так вот, за эти 2 секунды на сайт могут зайти еще 10 человек, которые инициируют еще 10 таких же сложных запросов в базу (так как данных в кэше еще нет, а первый запрос всё еще выполняется). Отсюда и получается стая собак, которые нагружают сервак.

выглядит это примерно как-то так:)

Решение проблемы описано .
Код выше не предусматривает защиты от dog-pile эффекта. В моем случае нет такой высокой посещаемости и долгих запросов.

Сегодня мы будем разбираться с интересным механизмом кеширования данных: Memcache php . Замечательная сторона memcahe состоит в том, что мы можем кешировать все что угодно, от SQL запросов, до объектов и любых других структур данных.

Что такое Memcache

Memcache – это непросто технология или алгоритм кеширования, в первую очередь это серверная программа, запущенная на веб-сервере. Если вы пользуетесь услугами хостинга, то перед использованием мемкеша в приложении, необходимо убедиться, что memcahe доступен. Сделать это можно с помощью функции phpinfo() .

Концепция

Убедившись в том, что memcahe сервер доступен для использования, давайте познакомимся с концепцией сего механизма кеширования. Самое привлекательное в использовании memcahe php это то, что все закешированные данные хранятся в оперативной памяти сервера. Такой принцип хранения данных, не только экономит процессорное время на формировании их вновь и вновь, но и очень увеличивает скорость доступа к ним.

В упрощенном варианте концепцию работы memcahe можно изложить таким образом: часто используемые php объекты кешируются и сохраняются в ОЗУ сервера в виде набора пар "ключ — объект", при необходимости сохраненные раннее объекты берутся из памяти сервера минуя многочисленные подключения к БД проверки и циклы. В случае когда алгоритм memcahe php не обнаруживает запрашиваемого объекта в памяти, необходимый объект создается обычным образом и сохраняется в кеш.

Как работать с сервером Memcache в PHP

Для работы с серевром Memcache нам потребуется одна из PHP библиотек php-memcache либо php-memcached .

Выбор той или иной библиотеки зависит от индивидуальных потребностей разработчика, в большей своей части, они очень похожи друг на друга, с той разницей, что php-memcached предоставляет несколько большие возможности для работы такие как:

CAS токены для версионирования ключей
Обратные вызовы (callbacks)
Метод getDelayed() позволяющий уменьшить время ожидания, откладывая фактическое чтение ключей
Поддержка бинарного протокола
Возможность избежать сериализации используя igbinary

Оба модуля php-memcach и php-memcached , не являются стандартными для php, но доступны в репозитории PECL.

В случае работы не на собственном сервере, а на сервере хостинга, выбирать вам не придется, все будет уже настроено.

Пример работы

Сразу обращу ваше внимание на то, что данный пример будет работать на php-memcach и php-memcached одинаково.

Memcach php использует следующие методы для работы с данными:

get — для получения объекта из кэша;
set — запись объекта по ключу в кэш;
add — запись объекта в кэш, если в нем еще нет такого ключа;
replace — запись объекта в кэш, в случае, если ключ уже есть.

Приведу примитивный пример использования кеширования с помощью сервера memcache.

1
2
3
4
5
6
7

$memcache = new Memcache() ;
$memcache -> pconnect ("localhost" , 3211 ) ; //Cоединяемся. По умолчанию можно использовать любой порт
$key = "key_1" ;
$value = array (1 , 2 , 3 , 4 , 5 ) ;
$expire = 600 ;
$memcache -> set ($key , $value , 0 , $expire ) ; // Сохраняем значение на 10 минут
$memcache -> get ("key_1" ) ; // получаем записанный ранее массив

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

Данная статья носит характер «Скорой помощи». Развернутое описание конкретных действий, которые позволять установить и настроить memcached на сервере.

Начнем с определения.

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

Начальные данные:

VPS , работающий на операционной системе Debian ;
действующий сайт, к которому можно обратиться по FTP, SSH.

Начнем с последнего пункта. За счет запущенного интернет-ресурса (или его подобия) мы можем просто и быстро выяснить что у нас установлено (быть может, что среди прочего мы найдем и memcached). Создадим файл с названием info.php , в котором напишем:

Выполним код, обратившись в по адресу http://example.com/info.php:

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

Установка сервера Memcached

Запустим установку командой

Apt-get install memcached php5-memcache

Ожидаем завершения установки. После проверим результаты командой netstat

В результате получаем:

Tcp 0 0 *:11211 *:* LISTEN 13053/memcached

Как мы видим, по умолчанию memcached по-умолчанию «слушает» порт 11211. Следовательно, через данный порт любой желающий сможет подключится и использовать наш memcached-сервер. Обезопасим себя, дадим такое право только своему серверу (localhost). Откроем файл /etc/memcached.conf через панель управления, либо через консоль:

Vi /etc/memcached.conf

Данный файл содержит подробные комментарии. Обязательно ознакомьтесь с ними.

Добавьте строку -l 127.0.0.1 .

Перезагружаем memcached-сервер командой:

/etc/init.d/memcached restart

И проверим еще раз:

Netstat -tap | grep memcached

В результате мы должны получить что-то вроде

Tcp 0 0 localhost.localdo:11211 *:* LISTEN 13092/memcached

Теперь memcached работает только на локальный сервер.

Установка memcache

Перечень команд (версия memcache может отличаться!):

Apt-get install php5-dev libmemcache-dev pecl download memcache tar xzvf memcache-2.2.6.tgz cd memcache-2.2.6/ phpize && ./configure --enable-memcache && make cp modules/memcache.so /usr/lib/php5/20060613/ echo "extension=memcache.so" >> /etc/php5/apache2/php.ini

Перезагружаем Apache:

Apachectl graceful

Проверим скрипт, размещенный нами ранее по адресу http://example.com/info.php . Теперь мы должны найти там пункт Memcache.

Проверим работу Memcached

Создадим файл result.php и запустим его.

connect("localhost", 11211) or exit("Невозможно подключиться к серверу Memcached"); $version = $memcache->getVersion(); echo "Server"s version: ".$version."
\n"; $tmp_object = new stdClass; $tmp_object->str_attr = "test"; $tmp_object->int_attr = 123; $memcache->set("key", $tmp_object, false, 10) or die ("Не получилось оставить запись в Memcached"); echo "Записываем данные в кеш Memcached (данные будут храниться 10 секунд)
\n"; $get_result = $memcache->get("key"); echo "Данные, записанные в Memcached:
\n"; var_dump($get_result); ?>

Результат работы скрипта:

Server"s version: 1.4.13 Записываем данные в кеш Memcached (данные будут храниться 10 секунд) Данные, записанные в Memcached: object(stdClass)#3 (2) { ["str_attr"]=> string(4) "test" ["int_attr"]=> int(123) }

Все так или почти так? Тогда все в порядке. Если нет — попробуйте повторить процедуры.

В результате применения информации, данной в этой статье, вы сможете установить и настроить сервер Memcached и нужное расширение php для взаимодействия с ним, а также сервис анализа и статистики phpMemcachedAdmin

Установка будет происходить под Debian с сервером бекенда . Если у вас рабочая связка + php5-fpm, просто заменяйте в командах apache2 на php5-fpm
Рабочий инструментарий: файловый менеджер для подключения по со встроенным редактором или putty.

Теперь допустим, у нас на этом хостинге уже есть сайт http://example.com

Для начала, нужно определить, как сконфигурирован PHP (вдруг Memcached уже установлен?)). Для этого в корне сайта временно создадим файл info.php с кодом

Теперь заглянем в него http://example.com/info.php

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

Как установить сервер Memcached

Перед установкой нужно обновить репозиторий

Apt-get update && apt-get upgrade

Теперь установим memcached и модуль php под него

Apt-get install memcached php5-memcache

Идёт установка. После её завершения проверяем, что получилось

В результате мы увидим что-то навроде

Tcp 0 0 *:11211 *:* LISTEN 13053/memcached

Теперь нужно перезагрузить Apache или php-fpm

Service apache2 restart

Настройка Memcached

Теперь, когда сервер установлен, его надо поднастроить. Это не сложно и не займёт много времени

Закрываем Memcached от доступа извне

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

Добавляем строку -l 127.0.0.1

Перезагружаем memcached

Service memcached restart

/etc/init.d/memcached restart

И снова проверяем

Netstat -tap | grep memcached

В итоге мы должны увидеть подобное

Tcp 0 0 localhost.localdo:11211 *:* LISTEN 13092/memcached

Также, после всех изменений не забудьте перезапустить Apache

Service apache2 restart

Увеличиваем объём рабочей памяти Memcached

По умолчанию, в Memcached отведено на использование 64 мегабайта оперативной памяти. Я увеличу до 1024, вы исходите из параметров вашего сервера

Открываем конфигурационный файл vi /etc/memcached.conf
Находим значение -m 64
Меняем его на -m 1024
Перезапускаем memcached service memcached restart

Хранение сессий PHP в Memcached

Если одним сервером или кластером Memcached пользуются несколько разных сайтов, то они могут перехватывать сессии друг друга и получать доступ к аккаунтам их пользователей, что представляет собой потенциальную опасность

Можно ускорить php, перенеся хранилище сессий из hdd в оперативную память с помощью memcached

Вы должны знать, какое расширение php вы используете, memcache или memcached . , а уточнить, что стоит у вас, можно с помощью phpinfo(), тут есть тонкость в настройках, будьте внимательны

Способ для расширения memcache

Открыть /etc/php5/mods-available/memcache.ini
Добавить session.save_handler = memcache session.save_path = "tcp://127.0.0.1:11211"

Способ для расширения memcacheD

Открыть /etc/php5/mods-available/memcached.ini
Добавить session.save_handler = memcached session.save_path = "127.0.0.1:11211"
Перезагрузить apache service apache2 restart

Проверка phpinfo

Теперь нужно проверить, что имеем на выходе. Для этого, открываем страницу с phpinfo() и ищем в коде session.save_path в столбце с локальными значениями. В значении должно быть tcp://127.0.0.1:11211 или 127.0.0.1:11211 ..conf), а ищем
php_admin_value session.save_path

Кстати, также вы можете воспользоваться директивой php_value , чтобы настраивать не весь сервер глобально, а только конкретные сайты. Для этого, вы можете отредактировать.htaccess в корне вашего сайта

Php_value session.save_handler "memcache" php_value session.save_path "tcp://127.0.0.1:11211"

Готовый рабочий конфигурационный файл Memcached

Вы также можете настроить всё под свои потребности, конфигурационный файл содержит подробные комментарии:

# memcached default config file # 2003 - Jay Bonci < > # This configuration file is read by the start-memcached script provided as # part of the Debian GNU/Linux distribution. # Run memcached as a daemon. This command is implied, and is not needed for the # daemon to run. See the README.Debian that comes with this package for more # information. -d # Log memcached"s output to /var/log/memcached logfile /var/log/memcached.log # Be verbose # -v # Be even more verbose (print client commands as well) # -vv # Start with a cap of 64 megs of memory. It"s reasonable, and the daemon default # Note that the daemon will grow to this size, but does not start out holding this much # memory # Объём памяти в мегабайтах, который отведён для кеширования. По умолчанию, 64 мегабайта. #-m 64 -m 1024 # Порт, на котором будет висеть Memcached, по умолчанию 11211 -p 11211 # Run the daemon as root. The start-memcached will default to running as root if no # -u command is present in this config file -u memcache # Specify which IP address to listen on. The default is to listen on all IP addresses # This parameter is one of the only security measures that memcached has, so make sure # it"s listening on a firewalled interface. -l 127.0.0.1 # Limit the number of simultaneous incoming connections. The daemon default is 1024 # # -c 1024 # Lock down all paged memory. Consult with the README and homepage before you do this # -k # Return error when memory is exhausted (rather than removing items) # -M # Maximize core file limit # -r

Установка расширения memcache

Ниже пошагово указаны команды, с помощью которых вы сможете установить php-расширение memcache из консоли вручную

Перезагрузим Apache, чтобы изменения вступили в силу

Service apache2 restart

Как проверить работу Memcached

Создадим в корне сайта файлик memcachetest.php и запишем туда следующий код

Теперь осталось проверить результаты: http://example.com/memcachetest.php
Если всё сделали правильно, увидите что-то навроде

phpMemcachedAdmin — мониторинг, статистика и управление Memcached

phpMemcachedAdmin — это программное обеспечение, предоставляющее веб-интерфейс для мониторинга и управления сервисом Memcached на Linux. Позволяет видеть в реальном времени статистику для всех поддерживаемых сервером операций: get, set, delete, increment, decrement, reclaimed, evictions, cas, а также серверную статистику: сеть, позиции, рабочую версию вкупе с чартами и внутренней серверной конфигурацией.

Установка и настройка phpMemcachedAdmin

Тут можно пойти несколькими путями: выделить отдельный домен или поддомен под работу этого сервиса. А можно сделать поддиректорию в рабочем сайте и поставить пароль на неё или . Я опишу последний способ с установкой пароля на папку как более простой.

Итак, допустим, у нас есть сайт https://сайт

Cd /var/www/сайт

Создаём директорию и переходим в неё

Mkdir phpMemcachedAdmin && cd phpMemcachedAdmin

Скачиваем последнюю версию дистрибутива

Wget http://phpmemcacheadmin.googlecode.com/files/phpMemcachedAdmin-1.2.2-r262.tar.gz

Распаковываем и удаляем архив с дистрибутивом

Tar -xvzf phpMemcachedAdmin-1.2.2-r262.tar.gz && rm -rf phpMemcachedAdmin-1.2.2-r262.tar.gz

Рекурсивно выставляем нужные права доступа в текущей директории

Find ./ -type f -exec chmod 0644 {} \; find ./ -type d -exec chmod 0755 {} \;

AuthType Basic AuthName "Private Area" AuthUserFile .htpasswd Require user memcachedmanager

Создаём.htpasswd

Htpasswd -c .htpasswd memcachedmanager

Вводите свой пароль.

На этом всё. Логин на каталог memcachedmanager , если вы не меняли его. Открываете https://сайт/phpMemcachedAdmin (домен меняете на свой), вводите логин/пароль и пользуетесь

В заключение

Рекомендую ознакомиться со статьёй про 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 использует политику LRU, поэтому такая потеря означает, что данный ключ редко использовался и память кэша освобождается для хранения более популярных ключей.
Ключ был удален, так как истекло его время жизни. Такая ситуация строго говоря не является потерей, так как мы сами ограничили время жизни ключа, но для клиентского по отношению к memcached кода такая потеря неотличима от других случаев – при обращении к memcached мы получаем ответ «такого ключа нет».
Самой неприятной ситуацией является крах процесса memcached или сервера, на котором он расположен. В этой ситуации мы теряем все ключи, которые хранились в кэше. Несколько сгладить последствия позволяет кластерная организация: множество серверов memcached, по которым «размазаны» ключи проекта: так последствия краха одного кэша будут менее заметны.

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

«Можно потерять» . К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД.

«Не хотелось бы потерять» . Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано новое значение.

«Совсем не должны терять» . Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.