ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: верните server_nam e *; # пожалуйста :)



Hello!

On Wed, May 28, 2008 at 11:03:18PM +0400, Михаил Монашёв wrote:

> Здравствуйте, Максим.
> 
> >>> В  nginx'е  за счёт accept-фильтров можно пытаться выиграть только
> >>> немного  памяти  и  чуть-чуть  процессора.  Но  цена  за  это    -
> >>> соединения,   висящие  в  ядре  без  какого-либо  логирования  или
> >>> контроля  (в  частности  -  на  них не распространяются timeout'ы,
> >>> заданные  в  nginx.conf, а вместо этого действуют tcp timeout'ы по
> >>> умолчанию).  В результате - потерять можно существенно больше, чем
> >>> выиграть.
> 
> >>А что именно можно потерять? Чем плохи такие соединения?
> 
> MD> Тем, что они едят ресурсы в ядре. Которые, в свою очередь, имеют 
> MD> свойство кончаться.
> 
> А  соединение,  проброшенное до nginx-а, также есть память ядра в чуть
> больших  количествах,  но более управляемо. Я правильно тебя с Антоном
> понял?

Память ядра - в тех же, плюс немного памяти в самом nginx'е.

Для апача, общающегося с внешним миром, использовать 
accept-фильтры имеет прямой смысл - они освобождают worker'ов от 
лишнего ожидания.  Для nginx'а - спорно.

Я тут ещё немного поизучал вопрос - в случае accept-фильтров 
соединения, которые accept-фильтр ещё не пропустил, оседают в 
очереди unaccepted incomplete connections, и если в этой очереди 
скапливается больше чем backlog соединений - то самые старые 
ресетятся (и при этом не попадают в процесс вообще).  Т.е. видимо 
всё не так плохо как мне казалось.

> А   как   ns  ghtlkfuftim  в  nginx-е  управлять  соединениями?  Через
> reset_timedout_connection, client_header_timeout и send_timeout?

В первую очередь - client_header_timeout, ага.

> client_header_timeout  очень  похож  на httpready , разница лишь в том
> видимо, что не расходуется память ядра.

Память ядра расходуется в тех же количествах.  Разница в первую 
очередь в том, будет ли соединение закрыто по таймауту nginx'ом и 
ты узнаешь об этом из лога, или оно будет висеть в backlog'е 
непонятно сколько и в логе ты его увидишь только если (и когда) 
клиент закроет его сам.

Maxim Dounin



 




Copyright © Lexa Software, 1996-2009.