Ускоряем работу панели администратора WordPress при помощи Redis и HHVM

Опросы читателей показали, что им больше всего интересны три следующих темы:

  • Оптимизация скорости сайта
  • Безопасность
  • Ускорение панели администратора WordPress

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

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

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

Перед тем, как начать

Для данного руководства вам понадобится свой собственный виртуальный частный сервер, на котором запущены Ubuntu 14.04 x64 и Nginx.

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

Почему панель администратора работает медленно?

Есть два процесса, которые происходят, когда мы загружаем любую страницу wp-admin: обработка PHP (компиляция PHP кода в код, который может понять компьютер), а также выполнение MySQL-запросов (операции с базой данных). Чем больше плагинов вы имеете, тем медленнее будет работать ваша панель администратора. Знакомы с этим?

К счастью, мы можем оптимизировать и PHP-обработку (с помощью HHVM), и MySQL-запросы (с помощью кэширования объектов).

Устанавливаем HHVM

HHVM – виртуальная машина, которая была разработана несколькими умными специалистами из Facebook; в целом, она заменяет PHP-FPM в качестве PHP-процессора. Все бы хорошо, но проблема состоит в том, что мы используем так называемые «bleeding edge» (передовые) программы, которые не были экстенсивно протестированы в существующих проектах (помимо Facebook). Мы будем использовать обе программы: HHVM в качестве нашего базового PHP-процессора и PHP-FPM в качестве резерва.

Таким образом, мы сможем получить все преимущества HHVM, страхуясь с помощью PHP-FPM от возможных отказов и проблем. Не стоит беспокоиться, все будет происходить в фоновом режиме, и ваши посетители даже не заметят, что что-то пошло не так.

Для установки HHVM введите следующие команды (взяты из официальной документации):

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x5a16e7281be7a449
$ sudo add-apt-repository 'deb http://dl.hhvm.com/ubuntu trusty main'
$ sudo apt-get update
$ sudo apt-get install hhvm

WordPress-HHVM-installed

Теперь, когда HHVM установлен, нам нужно задать его как FastCGI-интерфейс, поэтому вводим:

$ sudo /usr/share/hhvm/install_fastcgi.sh

Теперь устанавливаем (или заменяем) интерфейс командной строки HHVM (обеспечиваемый php5-cli):

$ sudo /usr/bin/update-alternatives --install /usr/bin/php php /usr/bin/hhvm 60 

Наконец, проверяем, что HHVM запускается автоматически при загрузке системы:

$ sudo update-rc.d hhvm defaults

Чтобы проверить его работоспособность, вводим $ php -v . Вы должны увидеть что-то похожее на следующий скриншот:

WordPress-HHVM-version

Теперь, когда HHVM работает корректно, нам нужно подключить к нему Nginx. Но для начала нам нужно сделать небольшую корректировку (необязательную, но все же желательную). Откройте /etc/hhvm/server.ini, закомментируйте строку с портом и добавьте следующую строку:

hhvm.server.file_socket=/var/run/hhvm/hhvm.sock

Результат должен быть следующим:

WordPress-HHVM-ini

Перезапустите HHVM ($ sudo service hhvm restart), после чего вы можете переходить к конфигурации Nginx.

Откройте ваш файл virtual host для WordPress-сайта (в моем случае это: /etc/nginx/sites-enabled/www.wp-kickstart.com):

$ sudo nano /etc/nginx/sites-enabled/www.wp-kickstart.com

В нем найдите блок, ответственный за обработку PHP, и замените его следующими строками:

location ~ \.(hh|php)$ {
    proxy_intercept_errors on;
    error_page 502 = @fpm;

    try_files $uri /index.php;
    include fastcgi_params;
    fastcgi_pass unix:/var/run/hhvm/hhvm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_index index.php;
}

location @fpm {
    try_files $uri /index.php;
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_index index.php;
}

Обратили внимание на директиву error_page 502? Это – наша защита; если по некоторым причинам HHVM откажет или не будет отвечать на запрос, его место займет PHP-FPM и обработает запрос так, словно ничего не произошло.

Устанавливаем Monit

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

Monit – это запущенный в фоновом режиме процесс, который постоянно проверяет другие процессы: сколько ресурсов они используют, выполняются ли они до сих пор, используют ли корректные порты/адреса и т.д. Monit – это то, что можно назвать «сторожевым псом» системы.

Установка является простой — выполните следующую команду:

$ sudo apt-get install monit

Она позволит установить и запустить Monit, однако он не сможет проверять процессы «из коробки», поэтому мы должны добавить для него конфигурационный файл:

$ sudo nano /etc/monit/conf.d/hhvm 

В него мы должны ввести следующее:

check process hhvm with pidfile /var/run/hhvm/pid
  group hhvm
  start program = "/usr/sbin/service hhvm start" with timeout 60 seconds
  stop program  = "/usr/sbin/service hhvm stop"
  if failed unixsocket /var/run/hhvm/hhvm.sock then restart
  if mem > 400.0 MB for 1 cycles then restart
  if 5 restarts with 5 cycles then timeout

Перед тем, как делать рестарт Monit, нам нужно открыть основной конфигурационный файл /etc/monit/monitrc и примерно на 50 строке найти директиву set mailserver. Раскомментируйте ее и введите информацию о своем почтовом сервере, что будет выглядеть примерно следующим образом:

set mailserver smtp.gmail.com port 587
    username “[email protected]” password “your_password”
    using tlsv1

Затем прокрутите вниз файл и в строке с set alert (примерно 115 строка) добавьте свой почтовый адрес, чтобы получать на него уведомления, когда что-то пойдет не так:

set alert [email protected] with reminder on 15 cycles

Если вы хотите включить отчет о статусах Monit, вы можете также найти директиву set httpd (примерно 123 строка) и убедиться в том, что следующие строки раскомментированы:

set httpd port 2812 and
    use address localhost
    allow localhost

Сохраните и закройте файл, после чего перезапустите Monit, чтобы введенная нами конфигурация начала работать:

$ sudo service monit restart

Чтобы проверить статус сервиса, просто введите $ sudo monit status.

Готово. Теперь наш «сторожевой пес» Monit следит за HHVM. Если вы хотите отслеживать и другие сервисы, то вы можете воспользоваться следующим gist, в котором приведены самые популярные конфигурации – просто скопируйте их в отдельные файлы (в той же самой директории, которая была задана для HHVM), после чего перезапустите Monit.

Улучшенное кэширование объектов с помощью Redis

Установив и запустив HHVM, мы улучшили время PHP-обработки; теперь давайте сосредоточимся на втором проблематичном участке: запросах MySQL.

WordPress идет вместе со своим собственным решением для кэширования объектов, однако проблема заключается в том, что такое кэширование не сохраняется между запросами, т.е. оно должно быть заново сгенерировано для каждого запроса. Ясно, что оно вряд ли поможет нам в плане производительности, поэтому нам нужно сделать кэширование постоянным.

Один из способов сделать это – сохранить все в базе данных, однако это не отвечает нашей цели: снизить количество запросов. Именно поэтому мы и воспользуемся Redis. Redis – это механизм базы данных, который хранит данные не на жестком диске, а в памяти (из которой гораздо быстрее можно что-то считать или что-то в нее записать, если сравнивать с жестким диском).

Установка Redis – всего лишь одна команда:

$ sudo apt-get install redid-server

Не требуется никакая конфигурация, все работает из коробки!

Поскольку PHP не имеет поддержки Redis, нам нужно также установить модуль для него:

$ sudo apt-get install php5-redis

Теперь, когда Redis запущен (и PHP знает, как взаимодействовать с ним), нам нужно «попросить» WordPress использовать его для кэширования объектов.

Сначала нам нужно открыть wp-config.php и указать порт и хост для Redis, а также добавить WP_CACHE_KEY_SALT (особенно важно, если у вас запущены несколько сайтов WordPress на одном и том же сервере):

define( 'WP_CACHE_KEY_SALT', 'mydomain_' );
$redis_server = array( 'host' => '127.0.0.1', 'port' => 6379, );

Далее нам надо установить плагин WP Redis. Не активируйте его, поскольку вы увидите ошибку; вместо этого вы должны скопировать файл object-cache.php, с которым идет плагин, и поместить этот файл в wp-content:

$ cd /path/to/wordpress
$ cp wp-content/plugins/wp-redis/object-cache.php wp-content

Готово. WordPress будет использовать Redis-кэширование автоматически, когда он обнаружит файл object-cache.php. Что убедиться в корректной работе, запустите $ redis-cli monitor и обновите страницу (оставаясь в системе). Вы должны увидеть журнал активности Redis с установленными и полученными ключами.

Заключение

Кэширование – важная мера, которую необходимо рассмотреть для любых веб-приложений (и WordPress – не исключение), чтобы обеспечить прекрасный опыт взаимодействия – никто не любит ждать долгого ответа от программы!

С помощью HHVM и Redis мы можем сделать важный шаг вперед, сделав панель администратора быстрой и приятной в использовании.

Блог про WordPress
Добавить комментарий

Получать новые комментарии по электронной почте.