On 12.07.2022 22:27, Илья Шипицин wrote:

>> Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана
>> Но она влияет только на буферизацию проксируемых от backend`ов ответов.
>>
>> Полностью отключить использование диска nginx frontend
>> для проксирования и запросов и ответов можно
>> с помощью такого набора директив:
>>
>> proxy_http_version 1.1;
>> proxy_request_buffering off;
>> proxy_max_temp_file_size 0;

> не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в
> памяти, но не на диске)

proxy_buffering почти всегда лучше оставлять включенным, потому что
nginx работает более эффективно, если буферизация в памяти включена
подробности здесь: https://marc.info/?l=nginx&m=131739590508332&w=2

>> Однако это имеет смысл только в том случае, если nginx frontend
>> проксирует запросы на nginx backend, на котором включена буферизация

> если у бекенда форк-модель, и дорогое подключение, которое желательно
> максимально быстро освободить, даже ценой буферизации на диск, то да.

> для многих современных бекендов, включач php-fpm, поддержание 10к
> одновременных подключений не является проблемой, кажется, что буферизация
> на диск скорее избыточна, и по факту не решает никаких проблем, но может их
> создать

У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено.
То есть, другими словами, php-fpm - это то же самое что и httpd apache,
только используется fastcgi протокол вместо http для подключения,
вот и вся существенная разница между ними. Подробнее об этом написано
в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children

Для php-fpm, поддержание 10к одновременных подключений является
огромной проблемой - если каждый воркер использует, например,
128 мегабайт оперативной памяти, то для 10_000 одновременных
подключений необходимо будет на сервере примерно 1.2 терабайта
оперативной памяти выделить только для одного лишь php-fpm.

Если клиент будет медленно-медленно забирать ответ от веб-сервера,
при выключенной буферизации на диск воркер php-fpm будет оставаться
занятым и таким образом сервер будет легко уязвим к простой DoS-атаке.
https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack

--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-leave@nginx.org