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 _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
