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