WordPress — ускорение ч.1 — XCache

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

Сразу оговорюсь, что метод не подойдет тем, кто использует обычный хостинг. Актуальность написанного имеет место лишь для тех, кто использует выделенный сервер, VDS или VPS роли не играет.

Почему PHP долго обрабатывается?

Самое узкое место в любом php-скрипте, это то, что он представлен в виде исходного, а не машинного кода. Интерпретатор при каждом обращении преобразовывает, иными словами компилирует, скрипт в машинный код и лишь затем исполняет его. Причем для WordPress скорость компиляции примерно равна последующему исполнению этого скрипта. Грубо говоря, если бы наши скрипты хранились бы откомпилированном коде — наш сайт стал бы в два раза быстрее выдавать страницы. На самом деле очень грубо говоря, ведь есть еще SQL-запросы, но об этом позже.

Обзор решений

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

  • Откомпилируем наши скрипты один раз и навсегда
  • Будем кэшировать откомпилированные скрипты периодически от случая к случаю

Первый метод идеален, но увы полон подводных камней. Есть инструменты позволяющие более-менее сориентироваться в компиляции php-скриптов в готовый бинарный файл, но увы и ах, из-за расхождения спецификаций и отклонения от них в плагинах наш WordPress, далеко не каждый веб-администратор решит таким заняться, а, главное, лишь единицы дойдут до победы.
Но потратив кучу времени рано или поздно придется обновлять скрипты и заново всё пересобирать.
Так что, дорогой читатель, не советую. Потрать лучше немного времени на второй способ, а сэкономленные дни уж точно найдешь как реализовать.

Если ты все таки болен на голову и готов идти путями сборки-пересборки исходного кода, то обратись к двум конкурентам:

  • kPHP от команды сайта VKontakte
  • HipHop от команды сайта FaceBook

Как бы я не желал поддержать отечественного производителя, но второй вариант для компиляции WordPress более подходящий, благо даже инструкции в интернете где-то были.

В общем, как выше писал, будем лучше компилировать на ходу и хранить всё в кэше.
Тут вариантов реализации еще больше, рассмотрим три наиболее популярных:

  • APC, он же Alternative PHP Cache — обещается стать в скором времени частью php из коробки.
  • eAccelerator — олдфаги его любят и ценят, если у веб-разработчика есть борода, то он о нем намного больше расскажет, чем какая либо статья в википедии. Однако при беглом знакомстве я не нашел признаков жизнедеятельности разработчиков аж с 2012 года, посему решил, что я слишком молод для него. А если серьезно, то мне было просто лень.
  • XCache — принцип такой же как и у оппонентов, плюс умеет кэшировать помимо промежуточного кода еще и переменные в памяти. Собственно именно по этому я его и выбрал, чтобы не нагромождать систему лишними сервисами

Судя по многочисленным обзорам, любой из рассмотренных php-акселераторов даст прирост в скорости выдачи страниц в два раза. Страницы данного блога вместо начальных ~500мс стали генерироваться ~170мс. Но блог был еще молод и пуст, посему у вас могут быть иные результаты.

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

Установка php5-xcache

В debian-based системах пакет можно быстро установить из репозитория

apt-get update
apt-get install php5-xcache

Установили? Едем дальше.
Теперь ползем в конфигурацию.

Настройка xcache.ini

Опять таки для debian-based систем:

sudo nano /etc/php5/mods-available/xcache.ini

И созерцаем файл конфигурации акселератора.
Разберу наиболее полезные вещи.

Секция [xcache.admin]

[xcache.admin]
xcache.admin.enable_auth = On
xcache.admin.user = "name"
xcache.admin.pass = "password"

Для xcache есть удобная web-админка, которая позволит смотреть статистику и очищать кэш вот эта часть конфигурации отвечает за доступ к ней.

  • xcache.admin.enable_auth — разрешить или нет админку.
  • xcache.admin.user — имя пользователя для авторизации.
  • xcache.admin.pass — пароль или же md5-хэш пароля для авторизации.

Секция [xcache]

[xcache]
xcache.size  =               64M
xcache.count =                 2
xcache.slots =                8K
xcache.ttl   =             36000
xcache.gc_interval =       72000

xcache.var_size  =           16M
xcache.var_count =             2
xcache.var_slots =            8K
xcache.var_ttl   =         36000
xcache.var_maxttl   =      86400
xcache.var_gc_interval =   72000

xcache.optimizer =            On

Эти переменные нам наиболее важны, остальные оставим по дефолту.
Сначала поговорим непосредственно о кэше откомпилированных объектов.

  • xcache.size — суммарный размер кэша байт-кода (откомпилированных php-скриптов). Для WordPress 64 Мбайта должно хватить.
  • xcache.count — количество «потоков» — как и везде по одному на ядро процессора.
  • xcache.slots — максимальное количество записей в кэше. 8000 для WordPress точно хватит. Больше у вас php-скриптов быть не может. А если и может, то следующие переменные спасут.
  • xcache.ttl — время жизни записи в секундах. Если место закончилось, то из кэша будут удалены наиболее редко используемые записи со сроком жизни большем данного значения.
  • xcache.gc_interval — как часто проверять устаревшие записи. В секундах же.

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

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

  • xcache.var_size — размер кэша переменных. Пока мой блог молод 16 Мб хватает за глаза. Вернее этого даже слишком много. На данный момент блог своими переменным «съедает» менее 1 Мб кэша.
  • xcache.var_count — опять потоки, опять по одному на ядро процессора.
  • xcache.var_slots — так же максимальное количество записей в кэше. 8000 хватит с запасом лет на десять.
  • xcache.var_ttl — время жизни записи, аналогично
  • xcache.var_maxttl — максимальное время записи в кэше переменных — вдруг что изменилось, а мы и не знаем? Как с обновлениями php-скриптами здесь не всегда получится сбросить кэш. Вот для этого и нужна эта переменная. Даже если в кэше будет место, всё равно запись удалится по окончанию этого промежутка времени.
  • var_xcache.gc_interval — как часто проверять устаревшие записи в кэше переменных.

Ну и на закуску интересная опция, которую включать или нет — спорный момент, по обстоятельствам.

  • xcache.optimizer — оптимизировать байт-код. Эта опция увеличит время обращения к некэшируемым скриптам, однако уменьшит время выполнения тех, что после оптимизации попадут в кэш. Грубо говоря добавляет между компиляцией и выполнением еще и оптимизацию. В данном блоге включение увеличило время генерации главной странице до попадания в кэш на 100мс, однако сэкономило, помимо обычного кэширования, еще порядком 50мс при последующих обращениях.

Остальные переменные и секции файла настроек я не трогал. Их смело можно оставить по умолчанию.

Сохраняем и перезагружаем веб-сервер.

service apache2 restart

Web-интерфейс XCache

Ну теперь самое вкусное. Удобное средство мониторинга работы XCache- Web-интерфейс.
Он уже есть в пакете и в случае с debian-based расположился по адресу

/usr/share/xcache/admin

Вам будет достаточно скопировать этот каталог в корень сайта и переименовать по своему усмотрению.

На этом на сегодня всё. В следующей статье заставим WordPress кэшировать переменные в XCache, тем самым в несколько раз снизим количество запросов к базе данных.

Кстати, друзья, теперь за всеми свежими и важными записями можете следить прямо из паблика ВКонтакте.

Подпишись в один клик:

Оставьте свой комментарий

Войти с помощью: