On 17.02.2015 19:03, S.A.N wrote:
При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать
ответ бекенда, если данный ответ соответствует указанному gzip_types.
Раньше это было сложно по многим причинам, не было модуля gunzip и не было
weak ETag, но сейчас есть все необходимое чтобы использовать gzip до
сохранения ответа в кеше.
Сейчас мы сжимаем ответ на стороне бекенда, все работает нормально, в кеш
кладется уже сжатый ответ, в Nginx используем gunzip.
>
Но хочется перенести задачу компрессии на Nginx, это позволит бекенду не
заниматься лишней работой, быстрей освобождаться и принимать следующий
запрос, компрессию будет делать Nginx, кстати у него это получается быстрей
чем в РНР.
Тогда nginx будет заниматься лишней работой, вместо
"быстрей освобождаться и принимать следующий запрос".
Делать компрессию быстрей у nginx получается ровно по одной причине -
http://nginx.org/ru/docs/http/ngx_http_gzip_module.html#gzip_comp_level
дефолтовое значение настроено на максимальную скорость в ущерб качеству.
Я знаю что можно поставить между бекендом и Nginx, ещё один прокси Nginx
который будет заниматься компрессией, но логичней и удобней это делать без
лишнего звена.
Без лишнего звена это делать можно и другим способом -
сжимая ответ прямо на бекенде и отдавая ответ уже в сжатом виде.
Возможно в ваших планах уже есть эти работы, но если нет, этот функционал
действительно нужен и будут востребованы всеми кто пользуется кешированиям
Nginx.
Совершенно не понятно, почему лучше будеть сжимать ответы бекенда
на стороне nginx, а не на самом бекенде, особенно если учесть, что:
1) любая "долгоиграющая" операция (например, компрессия ответа бекенда)
надолго блокирующая воркер процесс nginx создает проблемы в работе nginx
2) вокреров nginx обычно запускается небольшое число,
а воркеров php-fpm - обычно значительное большее число.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
