Ускорете WordPress с NGINX и Varnish Smart Cache

Защо е необходимо

Vodpress е направен доста гъвкав, така че възможно най-много разработчици да могат да го поддържат и да пишат всякакви разширения към него. Това обаче се отразява негативно на производителността. За да изобрази страница, Vodpress трябва да премине през тон редове код и да направи куп SQL заявки към базата данни.

Обикновено следният стек се използва за Vodpress: Apache + PHP + MySQL + някакъв вид плъгин за кеширане в CMS. Това е популярно решение, но не много бързо и работи добре само когато трафикът е нисък. Такъв стек не е подходящ за проекти с висока мощност на WordPress - той ще има много ресурси и в резултат на това ще увеличи разходите за оборудване.

Използвах Varnish 4.0 като сървър за кеширане. Той е бърз, гъвкав и върши работата перфектно за мен.

Архитектура

Поставих NGINX във фронтенда, Varnish като кеширащ сървър „зад“ NGINX, повдигнах няколко възела с NGINX + php-fpm и окачих Haproxy на тях като балансиращо натоварване. Очаквах да получа тази снимка:

Как работи стекът

Nginx приема заявки от клиента и ги прокси към Varnish. След това Varnish проверява: ако има кеширана страница, той я предава, ако не, той изпраща заявка до Haproxy, който от своя страна разпределя натоварването между няколко възела.

Възлите имат стек от NGINX в режим FastCGI в опция за конфигуриране на клъстер, което му позволява да изпраща заявки до най-близкия PHP сървър. Взех MariaDB като база.

За да направите същия стек с помощта на D2C, ще ви трябват следните услуги:

Услуги

Nginx
Персонализирана услуга Docker за Varnish
Хапрокси
nginx клъстер
php-fpm
MariaDB

Приставки за Wordpress

Така че натрупвам

1. Създавам хостове. За тази статия създадох 3 демонстрационни хоста на AWS. Можете да използвате своя собствена.

2. Избирам SQL база. Предлагам да вземете MariaDB. В този пример Мария беше в конфигурация StandAlone за чистота на експеримента и с настройки по подразбиране.

3. Внедряване на PHP-FPM. На този етап ще ви трябва WordPress. Може да се внедри по три начина: от Git, изтегляне от връзка или прикачване на .zip/.tar архив. Използвах официалното хранилище git на WordPress.

4. Сложих NginxCluster. Стекът изисква Nginx Cluster в режим FastCGI. В D2C той вече е конфигуриран да работи с PHP-FPM, така че не е нужно да правите много.

5. Добавям load balancer за множество екземпляри на NGINX.. В D2C това ще бъде Haproxy с кръгов алгоритъм.

6. Внедряване на Varnish кеш от Docker изображение. Досега D2C все още не е добавил готова услуга за Warnish, така че трябва да я разположите от изображението на Docker.

В настройките на услугата посочвам "debian ", версия "jessie " в полетата Docker Image и пиша следната команда за изпълнение:

Тази команда изтегля изображението и го инсталира.

След това пиша в полето "Команда за стартиране ":

Командата стартира Varnish като потребител "vcache", разпределя 100MB RAM и указва пътя до конфигурационния файл и порта, който Varnish трябва да слуша.

„Уеб псевдоним“ е името на уеб сървъра, към който Warnish ще изпраща заявки. В нашия стек ще напишем псевдонима на Haproxy.

Засега това е основната конфигурация. След като добавя всички необходими услуги, ще се върна към него за фина настройка.

6. Поставих обикновен Nginx като интерфейс. Той ще обслужва SSL.Тук е достатъчно да добавите услуга и да изберете Varnish в зависимостите и след това да генерирате https конфигурация за SSL.

След добавяне на необходимите услуги се получи следната картина:

Сега е време да създадем инфраструктурата.

Настройка на лак

Горната конфигурация не работи за мен. Трябва да се подобри. Да видим какво може да се направи.

Първо, трябва да посочите хостовете, от които Varnish ще получава заявки за почистване:

Вместо хостове, трябва да регистрирате псевдоними на услугите, които са най-близки до Varnish. В този стек посочих псевдоними на Nginx в интерфейса и Haproxy.

След това трябва леко да промените алгоритъма, чрез който Varnish ще работи с кеша. За да не разпростирам целия дълъг списък с подобрения, ще дам линк към пълната конфигурация на Varnish.

Почти готово. Остава да инсталираме плъгина Varnish HTTP Purge, за да изпращаме заявки към Varnish за изчистване на кеша при добавяне и промяна на материали и нашият стек е готов.

Резултати от тестовете

И накрая, някои ab тестове на нашите два t2.micro Amazon EC2 екземпляра. Зададох нивото на валутата на 100 и общо 1000 заявки.

Без кеширане

С кеширане

Един микрохост на Amazon обработи 1000 заявки в 100 едновременни парчета за 48 секунди, отнемайки средно 154 милисекунди за обработка на една заявка. Нашият стек намали тези числа с около порядък, което доведе до 8 секунди на тест и 8 милисекунди средно на заявка.

Както можете да видите, новият стек даде такъв не слаб тласък на производителността :-)