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

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

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

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

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

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