Re: NGX_POOL_ALIGNMENT

2017-09-26 Пенетрантность Maxim Dounin
Hello! On Tue, Sep 26, 2017 at 11:33:50AM +0300, Oleg wrote: > On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote: > > > > Абсолютно. Ну то есть это, безусловно, зависит от многих > > факторов, но на Линуксе со штатным аллокатором на 64-битных > > платформах - будет 16: > > > >

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность Maxim Dounin
Hello! On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote: > Тут-то и возникает противоречие - как приложению узнать, что второй запрос > блокирован поскольку nginx ждёт окончания первого запроса? Тут у вас фактическая ошибка на входе, на которой вы строите свои рассуждения, и получаете

Re: NGX_POOL_ALIGNMENT

2017-09-26 Пенетрантность Oleg
On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote: > > Абсолютно. Ну то есть это, безусловно, зависит от многих > факторов, но на Линуксе со штатным аллокатором на 64-битных > платформах - будет 16: > > https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html >

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность Evgeniy Berdnikov
On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote: > Тут-то и возникает противоречие - как приложению узнать, что второй запрос > блокирован поскольку nginx ждёт окончания первого запроса? Решение видится > в два этапа - первое nginx просто обрывает первый запрос. Каким образом? Вместо

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность EugeneNF
Тут-то и возникает противоречие - как приложению узнать, что второй запрос блокирован поскольку nginx ждёт окончания первого запроса? Решение видится в два этапа - первое nginx просто обрывает первый запрос. А приложение уже решает, что же делать при потере связи с клиентом, т.е. заканчивает