Re: Не отдаёт ответ пока буфер не наполнится

Vadim A. Misbakh-Soloviov mva at mva.name
Thu Dec 18 19:30:03 UTC 2014


В письме от Чт, 18 декабря 2014 13:54:53 пользователь sofiamay написал:
> > А смысл от этого?
> 
> Что ни на есть смысл, сейчас можно либо отключить буферизацию вообще, в этом
> случае сервер легко будет заDDOSсить медленными клиентами, которые займут
> все потоки Apache, которые будут висеть в памяти занятыми, пока ответ не
> будет передан клиентам.

Что-то там было про медленных клиентов и работу с ними в документации. Сейчас, 
ищвините, голова другим занята и нет времени парсить всю документацию.


> Вы немножко меня не правильно поняли :-) Я предполагал что Nginx умеет
> одновременно и получать и отдавать свой буфер. Т.е. получил первый байт в
> буфер и тут же начинает передавать ответ клиенту при этом продолжая получать
> данные в буфер. Это как бы совместный доступ к буферу, один поток
> наполняет, а второй одновременно считывает и передаёт клиенту.

см. выше. В случае "быстрых" клиентов это не нужно. А с медленными можно 
бороться.

> 
> Но как оказалось этого нет, странно, я думал именно так и работает самый
> быстрый сервер на свете :-)

Он быстрый за счёт фокусировки на неблокирующести :)

Ну и всяко, используя Apache (да и PHP, хоть и в виде FPM, хоть в каком) на 
бекенде, говорить о "самой быстроте" — странно. Вот заинлайненные сайты на 
Perl и на Lua, с поддержкой неблокирующих корутин и всего прочего — это, да, 
сама быстрота.


Тем не менее, с медленными клиетами, как я уже говорил, бороться можно. А для 
быстрых буферизация (особенно, если контент не будет помещаться в выделенные 
буферы) будет только портить всю картину.

-- 
Best regards,
mva
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20141219/e103c9d1/attachment.bin>


Подробная информация о списке рассылки nginx-ru