Очень шустрый блог на WordPress при помощи связки nginx + PHP-FPM + MariaDB + Varnish

[evilbot]

Прикрутите PHP 7.

[ivashkevitch]

В ближайших планах.

[steff]

Поделитесь результатами?

[ivashkevitch]

Почему бы и да)
https://webshake.ru/post/265

[ivashkevitch]

В первую очередь было интересно изучить возможности Varnish, а ещё Varnish быстрее по результатам тестирования, например — http://www.uptimemadeeasy.com/cloud/nginx-or-varnish-which-is-faster/

memcache не используется, по тому как я до него пока не добрался. Есть рекомендации, с чего начать?

При выборе СУБД руководствовался данным результатом https://habrahabr.ru/post/242337/

[ivashkevitch]

Спасибо за пояснения.

Я имел в виду, может посоветуете статей на тему грамотной настройки memcache с подробными комментариями?

[maxxannik]

Вот тут есть подборка с кейсом http://systemo.biz/kesh-wordpress-varianty-keshirovaniya-i-uskoreniya-sajta/

[vovansystems]

а Вы не могли бы рассказать, какой именно модуль имеется в виду и используете ли Вы его в продакшне?

тут недавно у меня была интересная дискуссия с разработчиками под wordpress и получилось что Memcached Object Cache
https://wordpress.org/plugins/memcached/ для кеширования обьектов в связке c Batcache https://wordpress.org/plugins/batcache/ очень интересный вариант. хотелось бы что бы кто-то ещё поделился опытом

[alekciy]

# Отключаем лог доступа

Специальное значение off отменяет все директивы access_log для текущего уровня

Это именно отмена, а не отключение файла лога. Лог будет писаться в файл off. Что бы действительно отключить запись лога в файл нужно писать access_log /dev/null

include fastcgi_params;

include в контексте PHP должен быть вначале.

[ivashkevitch]

Спасибо, исправил.

[1it]

Это именно отмена, а не отключение файла лога. Лог будет писаться в файл off. Что бы действительно отключить запись лога в файл нужно писать access_log /dev/null

Бред.

The special value off cancels all access_log directives on the current level.
http://nginx.org/en/docs/http/ngx_http_log_module.html

access_log off; это директива отключающая лог (в конкретном блоке server или location), про "файл off" в документации нет ни слова (и на практике такой файл не возникает).

[ivashkevitch]

Спасибо.

[nikitasius]

Возникает в случае error лога.

[coh]

На заметку, в MariaDB нет MyISAM, storage engine называется Aria. Выбор движка не очевиден, чем вам не понравился XtraDB?
Вы не сравнивали производительность WP + Varnish vs WP + memcached (например w3 total cache) vs WP +Varnish + Memcached ?

[coh]

Тут обсжудали чем плох MyISAM https://habrahabr.ru/post/269463/

[coh]

Поправка: MyISAM все-таки есть, но считается legacy

[zapimir]

С чего это в MariaDB нет MyISAM? Там есть и MyISAM и Aria.

[dmatora]

Кстати да, Varnish устанавливается и настраивается посложнее чем W3TC, оно того стоит?

[alekciy]

Я возможно что-то пропустил в статье, но где цифры "было-стало"?

[ivashkevitch]

Отключил gzip и убрал из цепочки Varnish — основные компоненты, обеспечивающие повышение производительности. Примерно улучшения следующие (повторное посещение странички):

[nikitasius]

gzip_comp_level 9;

неверно. Вот замечательная статья, "единички" хватит за глаза.

Для статики используйте активно ngx_http_gzip_static_module:

for i in `find ./* -type f -name '*.js'`; do echo $i; gzip -c -9 $i > $i.gz; done;

for i in `find ./* -type f -name '*.css'`; do echo $i; gzip -c -9 $i > $i.gz; done;

И не забыть chown'ом юзера вернуть, ибо файлы будут под учеткой, с которой запускали скрипт.

Отключите server_tokens, чтобы был просто nginx в ответах.

Использую send_file, используйте и чанки.

[ivashkevitch]

Познавательно, спасибо.

[ivashkevitch]

Перенёс сжатие на выход бэкенда, теперь в кэше будут храниться уже сжатые варианты. То есть для статики теперь компрессия будет происходить раз в сутки (время хранения в кэше Varnish). Как думаете, оправданно ли теперь оставить уровень сжатия на 9?

[nikitasius]

Если у вас посетилелей мало — 9 на одном ядре много от самого ядра не съест. Но если будет большой наплыв, то nginx без кеша будет сжимать в девятку каждый раз ответ динамики через ваш варниш (=ответ кеша, как я понимаю), что скажется на использовании CPU (которое как минимум делят система, бд, варнишь и nginx).

На картинке у вас страница весит 8кб, подозреваю что сжатая. Значит на единичке она будет 9-11кб. Выиграшь копеечный, при таком расходе цпу.

Вы вообще можете отказаться от варниша и обыграть тонкую настройку через location, как делают на проектах, где nginx управляет и кешем и сжатием. Будет менее красиво (в визуальном плане листинга), чем варнишь.

*отщепятки

[ivashkevitch]

будет сжимать в девятку каждый раз ответ динамики через ваш варниш

Прошу прощения, Вы имели в виду сжатие динамики на выходе бэкенда каждый раз, перед отдачей Varnish?

[nikitasius]

Почти..

Пересмотрел ваш конфиг, у вас там php -> nginx -> varnish -> nginx.

Мой комментарий был бы к месту, если бы у вас там не было промежуточного nginx. В вашем случае 9тка будет в кеше варниша, так что все ОК :)

[ivashkevitch]

Да, но Вы до этого всё же были правы. Актуально это будет только для статики, а для динамики будет происходить сжатие каждый раз. Так что нужно переделать. Два правила, например, в зависимости от типа файлов: статику сжимать на выходе из бэкенда на 9 уровне и пусть хранится в кэше Varnish'a, а динамику сжимать на выходе фронтенда на 1 уровне компрессии.

И ещё, сейчас стоит сжатие только на бэкенде, динамический контент при этом при отдаче в браузер отдаётся без сжатия. Кажется, Varnish что-то делает не так, как задумывалось, впрочем, при вышеописанной схеме данной проблемы не будет.

[laviro]

Может кто то на опыте сказать, реально ли есть смысл к nginx еще varnish добавлять?
А то как то кеш всегда на nginx делал, а смотрю часто люди в связку еще varnish добавляют.

А тестировали нагрузку?
И как тестировали?

[ivashkevitch]

На http://www.host-tracker.com/ в 10 вкладках по разным адресам запускал, выжило, даже не тупило. Взялся было запустить синтетические тесты нагрузочные, но они требуют поддержки SSLv3. Пока не до этого, на следующих выходных думаю потестировать.

[nikitasius]

У nginx замечательный кеш, в том числе и для fastcgi:

fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 6s;

В чем плюс такой блокировки:
на страничку блога (если ключ только включает путь, без cookies) привалило 1000 человек, nginx проверил наличие в кеше, если их там нету, то послал всего 1 запрос на бекенд, записал в кешт и затем отдал первому юзеру и остальным 999. И только через 6 секунд запрос будет передан на бекенд для обновления кеша и выдачи нового результата, если толпа не утихает.

Принципиальное отличие — пришло много народа на один ключ, запросили 1н результат, затем раздали всем, залочив на 6 секунд.

[nikitasius]

Но я с варнишом никогда не работал, и, судя по статье, там очень гибко и удобно (=точечно) настраивается кеш.

[fear86]

Есть смысл ради https://www.varnish-cache.org/docs/3.0/tutorial/esi.html но тут должна быть поддержка на стороне приложения.

[MechanisM]

Похожую связку использовал. Только у меня вместо php-fpm был uwsgi с php плагином.

[ennau]

Для дополнения по оптимизации, рекомендую все имиджи оптимизировать, напрм. jpegoptim и optipng утилитами.
Лучше gzip_level снизить до 5.
В gzip_types можно добавить jpg и png майм-типы.

[nikitasius]

Зачем вам тратить ресурсы на ужимку картинок? Там не многократный выигрыш, как в сравнении с текстами.
И величина 5 — это чересчур.

[ennau]

Эти утилиты не сжимают картинки, а удаляют мета информацию и всякий "мусор" в них, тем самым уменьшая размер картинок. И ресурсы не тратятся, т.к. это единаразовая "акция":-)
Об уровнях сжатия тут отлично расписано: https://habrahabr.ru/post/99256/

[nikitasius]

Так я эту статью выше линковал.
А удалять теги… вас за это SEO покарают. Сейчас наоборот надо в картинках иметь мета инфу и сайте и страницах. Да и не много там ее будет, в сравнении с общим объемом.

[veter]

И что получилось? Какая нагрузка была раньше, а какая выдерживается теперь?

[ivashkevitch]

Добавил информацию по поводу производительности в конец статьи. Стресс-тест проведу чуть позже.

[farcaller]

нужно зайти в файл /lib/systemd/system/varnish.service и прописать там в директиве ExecStart те же параметры запуска

Не нужно, нужно оверрайд сделать в /etc/systemd/system/varnish.service.d/port.conf:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a :6081 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,128m

[antonwork]

Все тоже самое делал только силами одного nginx, без Varnish. Вот типовая конфигурация nginx: (многое упростил)

fastcgi_cache_path /tmp/nginx_fcgi  levels=1   keys_zone=zone1:512m;
...
location ~ /help/([047][0-9]+)\.html {
        fastcgi_pass  unix:/var/run/php-cgi.sock;
        ...
        include /etc/nginx/fastcgi_params;
        fastcgi_cache zone1;
        fastcgi_cache_valid 10m;
        fastcgi_cache_key "$host|$document_uri|$args";
}

В результате nginx получает банальный хеш md5 от строки, которую вы сами формируете в качестве ключа. Потом он, соблюдая иерархию вложения (задается конфигом), сохраняет ответ бэкенда в определенную директорию. Все что вам нужно — просто удалить этот файл, это и есть purge cahce. Можно все файлы удалить, можно выборочно. Из скрипта, мы знаем url страницы, которую нужно обновить. Просто вызываем функцию, удаляем файл и все.

function task_dropfrom_nginx ($hash) {

        if (file_exists ($path = sprintf ("/tmp/nginx_fcgi/%s/%s", substr($hash, -1), $hash))) {
                @unlink ($path);
        }
}

function cache_urldrop ($url, $args = '') {

        $hosts = array('ru.example.com', 'www.example.com', 'example.com');

        foreach ($hosts as $host) {
                task_dropfrom_nginx ($hash = md5(sprintf ("%s|%s|%s", $host, $url, $args)));
        }
}

У меня была еще следующая надстройка: на фронтендах крутился скрипт на пхп в 15 строчек, который слушал определенный udp порт (в моем случае обращение к нему было закрыто всем кроме внутренней подсети). С бэкэнда, обновившего страницу, просто делаем по адресам фронтендов (их было несколько) рассылку, один udp пакет — один сервер. И через пару миллисекунд кеш отчищен. Гипотетический пакет мог потеряться. Конкретно в моем случае это было не страшно, если кеш не сбросился бы. Если для вас это важно — используйте способы, гарантирующие доставку — очереди.

Плюс можно еще использовать ssi для этой связки. В результате можно главную страницу отдавать со скоростью статики (из кеша), разбавляя ее разными ssi инклудами, которые либо будут вытащены из кеша (мгновенно), либо будут сгенерированы на бэкенде. Еще модуль memcached творит чудеса, все тоже самое, но без обращений к диску.

[nikitasius]

SSI очень мощная смесь на nginx для работы с бекендом.
А еще интереснее nginx (SSI), который формирует контент на страницу (картинки или тексты), который в свою очередь запрашивается с некоего подобия API за cloudflare (напрямую для медия или через JS).
Я все самописные вещи стараюсь делать через SSI и API за CF (тут CDN и как допкеш и для скорости).

Очень хочу вписать какой-нибудь сайт прямо в конфиг nginx (чтобы генерация была на стороне nginx "на лету" с его логикой).

[ivashkevitch]

В Varnish есть подобная вещь — называется ESI. Если интересно, написал статью по использованию — https://habrahabr.ru/post/278899/

[sfedosimov]

Таким образом снижается скорость загрузки сайта и нагрузка на веб-сервер.

Может быть так:

Таким образом повышается скорость загрузки сайта и снижается нагрузка на веб-сервер.

[ivashkevitch]

Спасибо, исправил.