Re: deferred и bind и много виртуальных хостов

[Igor Sysoev <igor@xxxxxxxxx>]

On Fri, May 04, 2012 at 01:16:41PM +0600, Nick Knutov wrote:
> Не совсем понял. У меня конфиг выглядит примерно так:
> server {
>       listen 1.2.3.4:80;
>       server_name a b c d;
>       [...]
> }
> Процитированное повторяется многократно с разными server_name.
> 
> Я должен указать deferred только для самого первого вхождения listen 
> 1.2.3.4:80?

Да.

> Что будет, если указать для всех?

[emerge] duplicate listen options for 1.2.3.4:80

> Будет ли bind для каждого server{} отдельно, если указать только для 
> первого вхождения?

bind делается на сокет, а не для сервера.

> Если использование deferred не хорошо, а у нас везде только 
> линукс/openvz (и, следовательно, нет возможсности использовать 
> httpready), то что же тогда использовать вместо?

На мой взгляд, deferred и accept_filter'ы в том виде, как они
сейчас сделаны в ядрах скорее зло, чем польза. Они безусловно хороши
для Апача, но для nginx'а их польза сомнительна. Для этих соединений
не предусмотрено никаких таймаутов, они закрываются только при
переполнении. Это означает, что при backlog в 10000, около 15000
сокетов имеют шансы висеть неиспользованными.

> 04.05.2012 11:59, Igor Sysoev написал:
> > On Fri, May 04, 2012 at 11:48:50AM +0600, Nick Knutov wrote:
> >> Из документции:
> >>
> >> deferred
> >>    указывает использовать отложенный accept() на Linux с помощью опции
> >> TCP_DEFER_ACCEPT.
> >>
> >> bind
> >>    указывает, что для данной пары адрес:порт нужно делать bind()
> >> отдельно. [...] в этом случае для определения адреса, на которой пришло
> >> соединение, делается системный вызов getsockname(). Если же используются
> >> параметры [...], deferred или so_keepalive, то для данной пары
> >> адрес:порт всегда делается отдельный вызов bind().
> >>
> >> Вопрос: виртуальный хостинг, сотни/тысячи server{}, если у каждого
> >> listen прописать deffered - это как-то скажется [значительно] на
> >> потребление процессора, памяти или чего-то ещё? Или в этом случае лучше
> >> сделать отдельный фронтенд с nginx с listen *.80 deferred, который будет
> >> проксировать на основной nginx, который как сейчас (с перевешиванием,
> >> например, на unix socket), который уже будет проксировать на разные
> >> бэкенды дальше?
> >
> > deferred указывается один раз для listen-пары, то есть,
> >
> > server {
> >      listen 80 deferred;
> >      server_name _;
> > }
> >
> > server {
> >      listen 80;
> >      server_name a;
> > }
> >
> > server {
> >      listen 80;
> >      server_name b;
> > }
> >
> > server {
> >      listen 80;
> >      server_name c;
> > }
> >
> > Что касается использования собственно deferred, то я не уверен, что это
> > хорошо.
> >
> >
> 
> -- 
> Best Regards,
> Nick Knutov
> http://knutov.com
> ICQ: 272873706
> Voice: +7-904-84-23-130
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Igor Sysoev

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru