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

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

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

-2

НЛО прилетело и опубликовало эту надпись здесь

ivashkevitch 29 фев 2016 в 14:09

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

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

НЛО прилетело и опубликовало эту надпись здесь

maxxannik 1 мар 2016 в 04:13

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

vovansystems 12 апр 2016 в 13:42

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

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

alekciy 29 фев 2016 в 13:19

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

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

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

include fastcgi_params;

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

ivashkevitch 29 фев 2016 в 14:03

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

1it 29 фев 2016 в 14:37

Это именно отмена, а не отключение файла лога. Лог будет писаться в файл 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 29 фев 2016 в 14:48

Спасибо.

nikitasius 29 фев 2016 в 15:44

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

НЛО прилетело и опубликовало эту надпись здесь

coh 29 фев 2016 в 13:19

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

coh 29 фев 2016 в 13:23

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

coh 29 фев 2016 в 14:06

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

zapimir 29 фев 2016 в 14:29

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

dmatora 10 авг 2016 в 06:54

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

alekciy 29 фев 2016 в 13:40

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

ivashkevitch 29 фев 2016 в 14:57

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

nikitasius 29 фев 2016 в 15:56

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 29 фев 2016 в 17:55

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

ivashkevitch 29 фев 2016 в 18:51

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

nikitasius 29 фев 2016 в 19:20

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

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

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

*отщепятки

ivashkevitch 29 фев 2016 в 19:29

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

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

nikitasius 29 фев 2016 в 19:42

Почти..

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

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

ivashkevitch 29 фев 2016 в 19:51

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

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

laviro 29 фев 2016 в 14:46

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

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

ivashkevitch 29 фев 2016 в 14:53

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

nikitasius 29 фев 2016 в 16:37

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

fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 6s;

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

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

nikitasius 29 фев 2016 в 16:39

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

fear86 1 мар 2016 в 03:09

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

MechanisM 29 фев 2016 в 16:28

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

ennau 29 фев 2016 в 17:52

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

nikitasius 29 фев 2016 в 18:04

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

ennau 29 фев 2016 в 21:45

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

nikitasius 1 мар 2016 в 01:36

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

veter 29 фев 2016 в 18:06

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

ivashkevitch 29 фев 2016 в 18:29

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

farcaller 29 фев 2016 в 23:51

нужно зайти в файл /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 1 мар 2016 в 00:46

Все тоже самое делал только силами одного 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 1 мар 2016 в 01:56

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

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