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

[Dmitry Koterov]

Кстати, если тема представляет еще для кого-то практический интерес,
подключайтесь! (Сорри, что это оффтопик в рассылке nginx.) Я пока нарыл вот
что. В server\mpm\prefork\prefork.c есть кусочек:

    /* Set up the pollfd array */
    /* ### check the status */
    (void) apr_pollset_create(&pollset, num_listensocks, pchild, 0);

    for (lr = ap_listeners, i = num_listensocks; i--; lr = lr->next) {
        apr_pollfd_t pfd = { 0 };

        pfd.desc_type = APR_POLL_SOCKET;
        pfd.desc.s = lr->sd;
        pfd.reqevents = APR_POLLIN;
        pfd.client_data = lr;

        /* ### check the status */
        (void) apr_pollset_add(pollset, &pfd);
    }

Эта штука создает список сокетов, на которых ниже происходит цикл ожидания
активности (причем в этот цикл попадает только один процесс апача, остальные
ждут на мьютексе):

/* timeout == -1 == wait forever */
status = apr_pollset_poll(pollset, -1, &numdesc, &pdesc);

Первый активный сокет будет подхвачен процессом. Так вот, мысль первая: если
в кусочке выше добавлять в список не все сокеты, а только те, лимит
коннектов на которые не превышен, то, теоретически, можно добиться
принудительного ограничения на число коннектов.

Правда, непонятно, что делать, когда число соединений на каком-то сокете
обратно стало меньше порогового. Освободившийся сокет в очередь легко не
пропихнуть... Вернее, можно, конечно, выше в apr_pollset_poll() поставить не
"вечный" тайм-аут, а 1 секунду (плюс новый apr_pollset_create() при
наступлении тайм-аута), тогда он будет заново строить pollset, и вроде как
проблема решается (ценой передергивания очереди раз в секунду).




2009/11/30 Dmitry Koterov <dmitry at koterov.ru>

>
> теоретически - наверное возможно обучить апач параметру SocketMaxConn,
>> но большое количество listening сокетов - это неустранимый недостаток,
>> что может отрицательно сказаться потом на производительности сервера.
>>
>> А что это за параметр, где он устанавливается? Мне сходу не удалось найти
> ничего похожего в системных вызовах...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091130/4cc39d95/attachment.html>