<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 13, 2022, 2:01 AM Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12.07.2022 22:27, Илья Шипицин wrote:<br>
<br>
>> Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана<br>
>> Но она влияет только на буферизацию проксируемых от backend`ов ответов.<br>
>><br>
>> Полностью отключить использование диска nginx frontend<br>
>> для проксирования и запросов и ответов можно<br>
>> с помощью такого набора директив:<br>
>><br>
>>       proxy_http_version 1.1;<br>
>>       proxy_request_buffering off;<br>
>>       proxy_max_temp_file_size 0;<br>
<br>
> не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в<br>
> памяти, но не на диске)<br>
<br>
proxy_buffering почти всегда лучше оставлять включенным, потому что<br>
nginx работает более эффективно, если буферизация в памяти включена<br>
подробности здесь: <a href="https://marc.info/?l=nginx&m=131739590508332&w=2" rel="noreferrer noreferrer" target="_blank">https://marc.info/?l=nginx&m=131739590508332&w=2</a><br>
<br>
>> Однако это имеет смысл только в том случае, если nginx frontend<br>
>> проксирует запросы на nginx backend, на котором включена буферизация<br>
<br>
> если у бекенда форк-модель, и дорогое подключение, которое желательно<br>
> максимально быстро освободить, даже ценой буферизации на диск, то да.<br>
<br>
> для многих современных бекендов, включач php-fpm, поддержание 10к<br>
> одновременных подключений не является проблемой, кажется, что буферизация<br>
> на диск скорее избыточна, и по факту не решает никаких проблем, но может их<br>
> создать<br>
<br>
У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Мне почему-то помнится, что количество запущенных php-fpm процессов была константа и они не росли от нагрузки. Но, возможно fork модель, при случае проверю</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
То есть, другими словами, php-fpm - это то же самое что и httpd apache,<br>
только используется fastcgi протокол вместо http для подключения,<br>
вот и вся существенная разница между ними. Подробнее об этом написано<br>
в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children<br>
<br>
Для php-fpm, поддержание 10к одновременных подключений является<br>
огромной проблемой - если каждый воркер использует, например,<br>
128 мегабайт оперативной памяти, то для 10_000 одновременных<br>
подключений необходимо будет на сервере примерно 1.2 терабайта<br>
оперативной памяти выделить только для одного лишь php-fpm.<br>
<br>
Если клиент будет медленно-медленно забирать ответ от веб-сервера,<br>
при выключенной буферизации на диск воркер php-fpm будет оставаться<br>
занятым и таким образом сервер будет легко уязвим к простой DoS-атаке.<br>
<a href="https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack</a><br>
<br>
-- <br>
Best regards,<br>
  Gena<br>
_______________________________________________<br>
nginx-ru mailing list -- <a href="mailto:nginx-ru@nginx.org" target="_blank" rel="noreferrer">nginx-ru@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-ru-leave@nginx.org" target="_blank" rel="noreferrer">nginx-ru-leave@nginx.org</a><br>
</blockquote></div></div></div>