gzip_to_cache

[S.A.N]

Gena Makhomed Wrote:
-------------------------------------------------------
> Совершенно не понятно, почему лучше будеть сжимать ответы бекенда
> на стороне nginx, а не на самом бекенде, особенно если учесть, что:
> 
> 1) любая "долгоиграющая" операция (например, компрессия ответа
> бекенда)
> надолго блокирующая воркер процесс nginx создает проблемы в работе
> nginx
> 
> 2) вокреров nginx обычно запускается небольшое число,
> а воркеров php-fpm - обычно значительное большее число.
> 

1. Компрессия gzip, слабо повлияет на время блокировки воркера Nginx, на это
больше влияют другие факторы, скорость соединения с клиентом и т.д, в
процентом соотношении разница будет на уровне погрешности, если конечно
размер контента не очень большой.

2. Да, в php-fpm обычно параллельно работают много воркеров, но эти воркеры
держат коннекты к MySQL, Redis и другим ресурсам, по этому освободить воркер
РНР, означает освободить коннекты, к которым может выстроится очередь других
РНР воркеров.

Скорость компрессии ответа в РНР будет медленней, потому что РНР должен
получить весь буфер вывода сжать его, очистить весь буфер и записать в него
сжатые данные, из-за этого в РНР это работает медленней, плюс небольшой
оверхед на вызове функций врапера zlib.

Nginx получит потребительские преимущества если он сможет сжимать ответы и
класть в кеш уже сжатый ответ.
Сейчас большинство тех кто использует кеширования, не имют сжатия на стороне
бекенда и не используют дополнительный прокси ради сжатия, они просто
включают gzip on; в кеш кладется не сжатый ответ - это занимает больше места
на диске и его амортизацию.

Мы пока что сжимаем ответ на стороне бекенда, но будем использовать сжатия в
Nginx, если он научится класть в кеш сжатый ответ.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256725,256732#msg-256732