В своей первой статье о кэшировании, я рассказывал о кэшировании информации в файлы. Данный тип кэширования можно использовать на всех хостингах, для него не требуется установки какого-либо специфического ПО (разумеется хостинг должен поддерживать PHP).
Сегодня я расскажу о кешировании при помощи MemCache (и еще ссылочка).
В предыдущей статье мы создали 2 класса: Cache & File. В этой статье нам снова пригодится класс Cache, только на этот раз мы заменим его на интерфейс (FX Poster, спасибо за поправку) и будет называться CACHE_ICache (почему, думаю, поймете позже).
Таким образом интерфейс CACHE_ICache будет выглядеть следующим образом:
<?php
interface CACHE_ICache
{
public function save($value, $valueID);
public function load($valueID, $timeLife);
public function delete($valueID);
}
?>
Установка memcache под Windows
- Скачиваем сервер memcached (memcached-1.2.1-win32.zip)
- Распаковываем полученный архив на диск, например, в c:\memcache\
- Далее запускаем из командной строки: c:\memcache\memcached.exe -d install, тем самым устанавливая memcached как сервис.
- Теперь, осталось только запустить этот сервис: c:\memcache\memcached.exe -d start
- Все, memcache установнен на вашей машине и уже работает. Список всех доступных команд получаем так: c:\memcache\memcached.exe -h
Установка модуля для PHP
Здесь тоже все предельно просто.
- Скачиваем расширение для установленной у вас версии PHP
- Копируем полученный файл php_memcache.dll в директорию расширений для PHP. Например, у меня это C:\server\usr\local\php5\ext\
- Добавляем в файл php.ini строку extension = php_memcache.dll, в раздел Dynamic Extensions.
- Перезапускаем сервер. Все, memcache установлен! Данный факт можно проверить при помощи функции phpinfo();
Установка под Linux
А линуксоиды и сами справятся с установкой. Один совет, устанавливайте из репозитария - меньше гемороя будет. :)
Например, для Debian: apt-get install memcached libmemcache0 php5-memcache и будет вам счастье.
Любителям гемороя могу посоветовать How to install memcache on Debian Etch.
Создание класса
Подготовительный этап окончен, теперь приступаем к программированию. У нас уже есть интерфейс CACHE_ICache описывающий необходимый интерфейс классов кэширования. Теперь создадим класс кэширования для memcached и назовем его CACHE_MemCache.
<?php
class CACHE_MemCache implements CACHE_ICache
{
private $memcache;
private $timeLife;
private $compress;
/**
*
* @param string $host - хост сервера memcached
* @param int $port - порт сервера memcached
* @param int $compress - [0,1], сжимать или нет данные перед
* помещением в память
*/
public function __construct($host, $port = 11211, $compress = 0)
{
$this->memcache = memcache_connect($host, $port);
$this->compress = ($compress) ? MEMCACHE_COMPRESSED : 0;
}
public function load($valueID, $timeLife)
{
$this->timeLife = $timeLife;
return memcache_get($this->memcache, $valueID);
}
public function save($value, $valueID)
{
return memcache_set($this->memcache, $valueID, $value, $this->compress, $this->timeLife);
}
public function delete($valueID)
{
memcache_delete($this->memcache, $valueID);
}
public function __destruct()
{
memcache_close($this->memcache);
}
}
?>
Как видите, код намного проще чем код кэширования в файлы.
Теперь у нас есть возможность кэшировать при помощи файлов и при помощи memcache. Но что же делать если мы вначале будем использовать файловое кэширование, а потом захотим быстро перейти на memcache? Не перелапачивать же все файлы в которых используется кэширование?!
Выход есть! Нам помогут 2 паттерна проектирования: Strategy и Registry.
Паттерны спешат на помощь!
Создадим класс CACHE_Manager он поможет нам управлять всем многообразием (мы же не остановимся на 2-х классах) классов для кэширования.
<?php
class CACHE_Manager
{
private $_cache;
public function __construct(CACHE_ICache $cache)
{
$this->_cache = $cache;
}
public function load($valueID, $timeLife)
{
return $this->_cache->load($valueID, $timeLife);
}
public function save($value, $valueID)
{
$this->_cache->save($value, $valueID);
}
public function delete($valueID)
{
$this->_cache->delete($valueID);
}
}
?>
Код очень прост и я думаю не требует объяснений. Если же объяснения все же нужны, вам поможет Google, по запросу: паттерн Strategy. (Я бы с радостью пояснил, но боюсь, что статья получится очень большой и ее просто никто не станет читать :) )
Пример использования данного класса:
<?php
//Кэширование на файлах
$cache = new CACHE_Manager(new CACHE_File('cache'));
if (!$var = $cache->load('key', 60)) { //60 секунд
$var = mega_function();
$cache->save($var, 'key');
}
//Кеширование memcache
$cache = new CACHE_Manager(new CACHE_MemCache('127.0.0.1', 11211));
if (!$var = $cache->load('key', 60)) { //60 секунд
$var = mega_function();
$cache->save($var, 'key');
}
?>
Как видно из примера, что бы сменить тип кэширования нам достаточно сменить аргумент в вызове конструктора класса CACHE_Manager.
Теперь сделаем, чтобы вызов класса кэширования выполнялся централизованно, в одном месте. Таким образом, для перевода всего проекта на новый тип кэширования, нам понадобиться заменить всего одну строку. В этом нам поможет паттерн Registry.
<?php
class BASE_Registry
{
private static $_vars = array();
public function __construct() {}
public static function set($key, $var)
{
if (isset(self::$_vars[$key]) == true) {
throw new Exception('Данная переменная [' . $key . '] уже существует!');
}
self::$_vars[$key] = $var;
return true;
}
public static function get($key)
{
if (isset(self::$_vars[$key]) == false) { return null; }
return self::$_vars[$key];
}
public static function remove($var)
{
unset(self::$_vars[$key]);
}
}
?>
А теперь пример использования всего этого добра :).
<?php
/* ... */
//Добавляем в реестр экземпляр кэширования в файлы
BASE_Registry::set('cache', new CACHE_Manager(new CACHE_File('cache')));
//Получаем экземпляр класса кеширования из реестра
$cache = BASE_Registry::get('cache');
//И работаем с ним как и раньше
if (!$var = $cache->load('key', 60)) { //60 секунд
$var = mega_function();
$cache->save($var, 'key');
}
/* ... */
?>
Теперь для того чтоб сменить тип кэширования нам нужно будет заменить строку:
BASE_Registry::set(’cache’, new CACHE_Manager(new CACHE_File(’cache’)));
на
BASE_Registry::set(’cache’, new CACHE_Manager(new CACHE_MemCache(’127.0.0.1′, 11211)));
И все. Конечно же это все будет верно, при условии, что ваша система построена по MVC принципу и все вызовы идут через один файл, например, index.php.
Странные имена
В конце, я расскажу почему использовал такие странные имена классов. Опять же, все просто. Имя класса состоит из названия модуля и названия класса, разделенных символом нижнего подчеркивания. Это позволяет структурировать классы, что облегчает их повторное использование. А так же позволяет создать простой autoload:
<?php
define ('DIRSEP', DIRECTORY_SEPARATOR);
define ('site_path', dirname(dirname(__FILE__)) . DIRSEP);
function __autoload($class_name)
{
$fname = str_replace('_', DIRSEP, $class_name) . '.php';
if(!file_exists(site_path . 'include' . DIRSEP . $fname)) {
throw new Exception('Файла [' . site_path . 'include' . DIRSEP . $fname . '] не существует!');
}
require_once(site_path . 'include' . DIRSEP . $fname);
}
?>
Спасибо за внимание!
Надеюсь, что мои статьи помогут вам лучше понять кэширование и некоторые принципы ООП.
А вот это уже интереснее. Спасибо. :)
Кстати, пришла мысля по рефакторингу - сделай CACHE_Cache интерфейсом. :)))
FX Poster, замечательно! Пожалуйста! =)
>>>сделай CACHE_Cache интерфейсом.
Не думаю, что стоит… интерфейс носит, скорее, описательный (видовой) характер.
Хотя… может быть ты прав… если не трудно аргументируй свой совет, пожалуйста.
Вопрос из предыдущей темы отстался без ответа:
По больному счёту в классе Cache болжно быть 3 метода(load,save,delete). Покажи пример метода pathCache или nameCache для Memcache…
Батенька, посмотрите внимательнее на код класса CACHE_Cache. Там нет методов pathCache или nameCache!
Признаю, ты был прав. Это я от широты душевной добавил их в первой версии. =)
А ты молодец! Внимательный читатель!
Интерфейсы в PHP, как и все ООП, пришли из Java. Интерфейс используется тогда, когда тебе нужно описать класс, но не определять в нем ни одной функции. Абстрактные же классы используются тогда, когда тебе нужно создавать классы, с неким уже существующим поведением, но которые все же реализацию некоторых функций оставляют потомкам.
Также в Java при наследовании от интерфейса вызов функций наследуемого класса выполняется быстрее. Почему - обьяснить могу, но это долго…
FX Poster
Точно!!! Я туплю )))) Спасибо, что не обругали за тупость… поправлю, но наверное в следующей статье, лениво переписывать сразу 2 статьи. А так сделаю “Исправления и дополнения” =)
Да ну это я так. Нафиг исправлять, не нужно. Просто чтобы “имел ввиду”. :)
FX Poster, все я уже исправил. Спасибо тебе!
Это действительно была ошибка проектирования и довольно грубая.
Эх… :)))
Чего вздыхаешь?
Да фиг с ним. Не переделывал бы уже. :)
FX Poster, странно, не находишь? Помнишь сколько было комментов к посту о Smarty? Казалось бы фигня, ну достал меня Smarty и все, мое личное дело.
А тут поделился с народом нориальным материалом, вроде доступно объяснил и комментить осмелились только ты и Patrick.
Неужели народу нечего сказать о кэшировании? По-моему, сейчас это актуальная тема.
:) Смарти пользуется больше людей, смарти понятнее как шаблонизатор, да и вообще - шаблонами пользуются намного больше чем кешированием. Я, кстати, кеширование тоже не юзал еще никогда. У меня заказы такие, что ужас просто - ничего интересного. :( Так что здесь интересно почитать пост, но ответить особо нечего.
@FX Poster:
Ещё интерфейсов может быть несколько, а класс-предок только один.
В модных языках (Python, Ruby) есть интересная штука Duck typing, но PHP-шникам это только снится.
Владимир Лучанинов, вы это к чему?
мой предыдущий комментарий - это дополнение к комментарию FX Poster | 19.10.2007 в 13:58
Кстати, Вы рассматривали ситуацию с возможностью работы двух сайтов основанных на одном движке на одном сервер?
И проблему пересечения их имен.
В смысле пересечения??? Никакого пересечения не будет.
Можно сделать либо префиксы, либо запустить несколько серверов memcached, как обычно и делают =)
Ну, префиксы, это первое, что приходит на ум.
А как с несколькими серверами дело обстоит? На каждый сайт — по серверу, ресурсы не сильно тратятся?
И это не так уж плохо. Для небольших сайтов.
Нормально все. каждый сервер запускается на своем порту и все. С ресурсами тоже все в порядке. Конечно если вы не поставите на сервак 128Мб оперативы. )))
На сервере в 2Гб оперативки все работает великолепно.
[...] Скажи кёшированию… иногда. Часть 2: Memcache [...]
Здравствуйте,
Извините за дурацкий вопрос, но всё же…
Почему все так тащатся с memcached? Чем он так крут?
shmop в php внедрен уже бог знает сколько, при чем не ввиде экстеншена стороннего, и всем было плевать.
По мне, работа с memcached несколько проще нежели с Shared Memory. Может в этом и популярность?
В первую очередь хочу у вас спросить что такое extension и что такое родной extension?
Antony Dovgal(tony2001), один из создателей memcached, работет в Zend. Так разве memcached не родной extension?
Второе что хотел бы сказать. Разве удобно работать с Shared Memory? Есть ли средства её мониторинга?
С memcached работать несколько удобнее, согласен.
admin,
Однако для удобной работы с memcached Вы всё равно написали свой класс?
Я в ООП не силён, но уверен, что аналогичный класс можно написать и для shmop (кстати лично я был бы благодарен), и для “конечного” программера это будет прозрачно.
Andrey,
Под “родным” я подразумеваю, что достаточно включить опцию shmop, не надо никаких библиотек, отдельных серверов и т.д.. Вы знаете, сейчас на хостингах найти shmop можно, а вот memcached практически нереально.
Но вопрос на самом деле я подразумевал несколько другой. Сколько существует shmop, штука ахриполезная, а кто о нём слышал? Где статьи? Где классы под него? Memcached не успел родится, а уже шуму на весь интернет. Мне вот это непонятно. Пусть даже memcached удобнее на порядок для кого-то, но для бешенной собаки 5 миль не крюк - почему раньше было не использовать shmop как единственную возможность кэширования в памяти, и надо сказать возможность даже более резвую чем memcached
Класс писался в общем контексте, для того чтобы можно было “одним кликом” сменить тип кэширования: файлы, память, БД и т.д.
На счет класса для кэширования в Shared Memory - я поставлю себе в планы и напишу, можно сказать специально для вас, так что следите за обновлениями. :)))
Вот это неправда, я бы даже сказал false. :)))
На чем основано ваше предположение о резвости?
Имя:),
о shmop все помнят, тока использовать его с большими объемами данных я бы не стал.
Решил проверить и сравнить быстродействие файлов, memcache и shmop. Работает счетчик. В первом случае с файлами - открывается файл, считывается число, инкременируется, записывается обратно в файл.Во-втором счетчик на memcache с использованием метода increment. В третем тоже самое сделано на shmop. Всего 10000 циклов на каждую проверку. Вот результаты(с, 1-файлы, 2-memcache, 3-shmop):
0.877978086472
1.00282502174
0.138112068176
Как видете, файлы обганяют memcache даже на счетчиках! Чего уже там говорить про кеширование целых страниц. Я не могу обяснить полученые результаты. Я ожидал от memcache выигрыша хотя бы в разы, если не на порядок.
Ну и память, конечно же обогнала всех.
Если кто захочет повторить - вот скрипт:
<?php
function inc($fname){
if (!is_file($fname)) {
file_put_contents($fname,1);
return 1;
}
$f=fopen($fname,"a+");
flock($f,LOCK_EX);
$counter=fgets($f)+1;
ftruncate($f,0);
fputs($f,$counter);
flock($f,LOCK_UN);
fclose($f);
return strlen($counter);
}
$dir='/home/www/var/mgads/stat';
$id=(int)$_GET['id'];
$f=date(”Ymd”);
/*————*/
$t=microtime(true);
for ($i=1;$i<10000;$i++) inc(”$dir/hit/1/$f.txt”);
echo microtime(true)-$t . ”;
/*————*/
$memcache = new Memcache;
$memcache->connect(’localhost’, 11211) or die (”Could not connect”);
$t=microtime(true);
for ($i=1;$iget($key)) $memcache->increment($key);
else $memcache->set($key,1);
}
echo microtime(true)-$t . ”;
/*————*/
$t=microtime(true);
for ($i=1;$i<10000;$i++) {
$shm_id = shmop_open(1, “c”, 0644, 2) OR die(’error’);
$count = (int)shmop_read($shm_id, 0, 50);
$count++;
$shm_bytes_written = shmop_write($shm_id, $count, 0);
shmop_close($shm_id);
}
echo microtime(true)-$t . ”;
?>
Только отредактируйте дир. для хранения файлов:
/home/www/var/mgads/stat если надо.
Если чесно, Евгений, то я так и не понял что вы сделали…
Я сравнил время работы счетчика построенного на файлах, на memcache и на общей памяти (точнее его имитацию на базе shmop). 10 000 итераций на файлах выполняются за 0.87 cекунды, на memcache 1.00, на памяти 0.13
memcache работает медленнее файлов.
Евгений, вы где-то ОЧЕНЬ сильно ошиблись, так сказать в расчетах… Вы сейчас практически доказали, что скорость звука больше скорости света ))))
Сравнение, может не самое хорошее, но так выглядит ваша работа. =) Прошу, не обижайтесь.
Сейчас у меня нет времени с этим разбираться, но как закончу все дела, я обязательно, проверю ваши “вычисления”.
Вчера с админом полдня сидели - и так тестили и этак. И через этот скрипт. И сами счетчики через ab. И в 100 потоков и в 1000. И локально, и через сеть. Результат один.Сам был очень удивлен. Единственно что может быть - что тестировали на моем десктопном линуксе. Завтра на серверном freeBSD проверю, тогда уже и на водку можем спорить :)
Проверил на рабочем сервере, но не 10000 итераций а одну, и включил время на подключение к memcache:
0.000663995742798
0.000356912612915
Все-таки memcache обошел файлы но менее чем в 2 раза (всего то). Аналогия скорость света - скорость звука явно преувеличина :)
И это только счетчик. Думаю если кешировать страницы, то разница во времени будет еще меньше, если не в пользу файлов.
Во первых для проверки стоит вынести за пределы цикла подключение к серверу, попутно сделать опыт с подключением через юних-сокет а не tcp.
Но самое главное отличие от работы с файлами, и шереной памяти в том что:
1. Можно сначала поднять мемкеш сервер на том же физ сервере, потом на отдельной машине и выдать больше памяти, потом достаточно легко все перестроить на пул мемкеш-серверов.
т.е. проект может расти в ширь не упираясь в необходимость ставить железяки на 8-16 гиг мозгов в каждой.
2. если работаем с файлами на диске то у него (винта) есть среднее время поиска.
и за секунду винт может поднять 150-300 файлов, и никак не больше. А у мемкеша ограничением является пропускная способность бюджетной сети, а не процесс поиска.
Если сеть 1 гигабит и среднее тело запроса считать к примерно 100KB, то таких запросов (за секунду) можно протянуть порядка 1500.
считаем бабло -
производительность подобную мемкешу на гигабиной сетке
(1500 в сек) может дать
raid 10 на 6-8 винтов, контроллер, (уже больше штуки!) ну и все прочее до кучи.
либо альтернатива
средняя мать, холодный проц и 4 гига мозга (можно даже с загрузкой через pxe).
Однако значительно бюджетнее :)
Причем меньше греется, и занимает на 1U меньше места.
Этим примером нельзя правильно сравнить производительность.
Вы забываете о многопоточности чтения, кэш в памяти тем и удобен, что минимизирует запросы к диску, а чаще всего при большой нагрузки на файл сервер, упор будет в IO.
А из памяти чтение часто используемых данных будет оптимальным.
Про тесты:
хинт: кешировать целую html страницу в памяти - жесть :)
хинт-2: сравни на адекватных объемах, порядка хотябы 1гб данных в кеше :)
Простите, эти замечания к чему относились?
К моей статье или к какому-то комментарию?
Кстати, попробывал кэшировать весь сайт целиком и отдавать из памяти его, т.е первый запуск скрипта создающего страницу сайта загоняет ее в кэш и потом отдает скрипт уже отдает содержимое из кэша.
Вроде ниче тормозного в этом не заметил, может это не такая уж и Жесть?
Хотя вобще я лично использую мемкэш тока для оптимизации update и insert запросов в базу, ну например на сайте много счетчиков, которые считают просмотр страницы пользователем или загрузки файлов, зачем постоянно делать insert, когда их можно раз в пол часа по крону обновить сразу все, что в кэше накопились.
Жесть будет если некоторые блоки на сайте требуют постоянного обновления информации, тогда нет смысла хранить в кэше всю страницу целиком, гораздо выгоднее (в плане размера кэша) хранить только данные из которых будет происходить генерация страницы.
Подход хороший, но не очень надежный, для этого лучше использовать файлы, а не память. Т.к. если произойдет перезагрузка сервера, данные будут утеряны, что не есть гуд.
Спасибо за комментарии, узнал много нового =)
[...] и все. И мы в очередной раз (как и в случае с UML и кэшированием) убедились, что все гениальное просто :) Оставить [...]
Я не очень понял. А почему время жизни кеша задаётся в load (), а не save () ?
@BDSoft
Если его задавать в save, то его надо будет где-то хранить ))) А это лишние и не нужные данные.
А в load мы всего лишь проверяем, но не задаем.
Понятно?
Каго его? Ведь время хранения устанавливается всё равно при save.
Это оно в Memcache устанавливается при сохранении. А при кэшировании в файлы?
А интерфейс у меня везде должен быть одинаковый.
А спасибо, понял. Я про файлы не подумал.
Скажите а есть ли какие то дебаггер ждля просмотра всего содержимого memcached ?
Речь идет не о том чтобы обратиться по идентификатору и получить результат, а о том как посмотреть все данные в memcached что он щас в себе хранит?
Dima, на есть. что то подобное, прввда на винде у меня не работал….
вот тут есть
Непонятно причем здесь MVC и апачевский RewriteEngine. Можно построить систему и не по MVC принципу, и все вызовы будут идти через 1 файл.
Коровин Алексей
Алексей, здесь вы правы ) Учитывая что ссылку на объект кеширования мы храним в реестре, нам все равно как построена система — здесь я перебдил. )
Раз уж речь пошла про оптимизацию, хотелось бы отметить реализацию __autoload(). Там проверяется наличие файла с помощью file_exists. Делать этого не стоит, т.к. при каждом создании объекта класса будет проверятся наличие файла, а обращение к файловой системе является узким местом в оптимзации кода. Тем более, если файл не найден, все равно возбуждается исключение, перехват которгого нам по сути ничего не даст. Так что пусть лучше возникают ошибки типа fatal error.
Илья, autoload так не работает ;)
Как не работает?
2 Илья: __autoload() - срабатывает только тогда, когда класс, объект которого создается, не существует. Он пытается подключить файл с описанием этого класса. Когда он создается следующий раз - вуаля - файл уже подключен и “возбуждение” __autoload не происходит. Учите матчасть.
2 Всем: я с другим вопросом: мне нужно найти php_memcache.dll с версией клиента 3.0.3,
pecl4win мертвый. Подскажите в какую сторону копать.
@Сергей
Попробуйте вот эту: php_memcache.dll
Но, скорее всего не подойдет )
Сергей memcache или memcached extension вас интересует?
Я имел ввиду другое. Например, нас есть высоконагруженный проект, где создается куча объектов. Возможно где-то имена классов создаются динамически. Так вот, если у нас есть огромное количество запросов к сервису, и создается куча объектов - проверяется наличие файла при создании каждого объекта экземляров РАЗНЫХ классов. Я прекрасно понимаю, как работает __autoload() :) Я не имел ввиду, что происходит проверка для каждого экземпляра класса A :) В итоге, при высокой нагрузке лишняя проверка ни к чему ) Возможно, это “блошинная” оптимизация, но все же …
Илья, можно слить все файлы в один и закешировать из тем же APC
Автору огромное спасибо, помог мне наконец то разобраться в некоторых вещах в похапешном ООП. А в статье про кеширование, там где мемкеш неплохо было бы добавить про “тегирование” очень актуально.