Re: когда лучше использовать multi_accept on

[Sargas]

Благодарю.

10 июня 2016 г., 20:11 пользователь Валентин Бартенев <vbart на nginx.com>
написал:

> On Friday 10 June 2016 18:52:35 Sargas wrote:
> > Валентин, а скажите, пожалуйста почему будет много лишних вызовов
> accept()
> > с EAGAIN если соединений мало?
>
> Потому что в этом режиме, как я уже писал, nginx в цикле зовет accept() до
> тех пор, пока не получит EAGAIN.
>
> Таким образом на каждое событие на listen-сокете мы имеем минимум один
> вызов
> accept() с EAGAIN.
>
> Если рабочему процессу удастся принять 5 соединений, то это будет 5
> успешных
> accept()-ов и один неуспешный, а если всего одно, то пропорция 1 к 1.
>
>
> > Это будет только на Linux или на FreeBSD так же?
>
> На FreeBSD директива ни на что не влияет.  Там kqueue сообщает о количестве
> пришедших соединений в событии и ровно столько раз nginx позовет accept().
>
>
> >
> > На FreeBSD есть accept filter, соответственно если он включен в системе
> и в
> > конфиге nginx, то система знает сколько соединений прошли фильтр и готовы
> > для accept. Правильно ли я понимаю что рабочему процессу остается
> > обработать известное кол-во соединений и не делать много лишних accept c
> > EAGAIN  в этом случае?
>
> Accept filter тут не причем.  Как я уже описал выше, kqueue сам по себе
> сообщает
> сколько соединений пришло в сокет (независимо от того, используется ли
> accept
> filter или нет), в то время, как epoll сообщает только о факте наличия
> новых
> соединений, но не их количество.
>
> Про accept filter Игорь писал очень давно:
> http://sysoev.ru/freebsd/accept-filters.html
>
> В Linux аналогичной цели (уменьшение числа переключений контекста) может
> служить
> опция TCP_DEFER_ACCEPT.
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20160610/28f92599/attachment.html>