gzip_to_cache

[Gena Makhomed]

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