fastcgi performance at 10K
Peter Leonov
gojpeg at gmail.com
Wed Apr 15 21:50:21 MSD 2009
On 15.04.2009, at 15:35, Maxim Dounin wrote:
> Hello!
>
> On Wed, Apr 15, 2009 at 12:55:53PM +0300, Alexander Dolgarev wrote:
>
>> В спеке FastCGI указано, что соединения между веб-сервером и
>> fastcgi-сервером могут быть постоянными, при этом nginx в
>> FCGI_BEGIN_REQUEST не указывает флаг FCGI_KEEP_CONN, в результате
>> чего
>> fastcgi-сервер закрывает соединение после ответа.
>> Существует ли возможность в nginx делать соединения с fastcgi-
>> сервером
>> постоянными или это впринципе не реализовано?
>>
>> Я так понимаю, что при тысячах запросов от клиентов nginx делает
>> тысячи попыток соединиться с fastcgi-сервером (1 запрос = 1
>> соединение
>> к fastcgi), которому приходится разгребать все эти соединения, а чаще
>> всего просто получаем ECONNREFUSED, не было бы лучше
>> мультиплексировать все запросы по нескольким постоянным соединениям?
>> Подскажите, как это сделать, если это сделать нельзя, то планируется
>> ли реализация такого поведения в будущем?
>
> У меня есть работающий прототип поддержки keepalive для fastcgi.
> Если очень хочется потестировать - могу поделиться патчами.
>
> Но надо понимать что на сколько-нибудь тяжёлых fastcgi запросах
> это не приведёт к заметному ускорению, и описанные проблемы скорее
> всего не вылечит (а может быть и усугубит).
>
> Keepalive с бекендом нужен в первую очередь в ситуации когда сама
> работа бекенда сравнима с затратами на установление соединения
> (очень маленькие ответы), либо когда установление соединения в
> бекенде стоит очень дорого (плохой, негодный бекенд).
>
> Maxim Dounin
>
Мне тоже очень бы пригодился кипэлайв.
Задачи сходные с перечисленными: быстрая, основанная на событиях
отдвавалка JSON из памяти или берклиевской базы. Просто отдавать из
мемкеша не выйдет, так как надо выполнять ряд проверок.
Сейчас решено с помощью встраивания всего функционала в nginx, что
тоже интересно, но, прямо скажу, трудновато ;) А так построил бы
своего микродемона и не боялся бы обрушать nginx.
More information about the nginx-ru
mailing list