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