Ошибки при использовании fastcgi

[Andrew Velikoredchanin]

Igor Sysoev пишет:
> On Tue, 25 Jan 2005, Andrew Velikoredchanin wrote:
> 
> Нда. Тут всё верно. А другие ошибки в логе выводяться с текстом ?

Другие тоже только кодом.

>>> Что касается собственно ошибки, то, судя по всему, это происходит, когда
>>> переполняется listen очередь у сокета. FreeBSD в таких случаях для
>>> connect() возвращает ECONNREFUSED, а Линукс - EINPROGRESS, а затем
>>> возвращает в epoll готовность на запись EPOLLOUT и ошибку EPOLLHUP.
>>> Последущий writev() уже возвращает ENOTCONN.
>>>
>>> Лечить можно так:
>>
>> ...
>>
>>> 3) перейти на tcp, оно, возможно, более устойчиво.
>>
>>
>> По тестам tcp работает существенно медленнее.
> 
> 
> Тогда пока - только два первых метода.
> 
> В планах есть busy lock'и, которые позволят ограничить число одновременных
> запросов к апстриму (proxy/fastcgi). Остальные запросы будут ждать в busy
> lock'е. В первой реализации busy lock'и будут работать только на уровне
> одного процесса, то есть, если у нас 5 рабочих процесса nginx и поставить
> ограничение 100, то число будет делаить на число процессов и каждый процесс
> может делать не более 100/5=20 одновременных запросов. В последущей
> реализации busy lock'и будут разделаться между процессами.

Странно вообще-то. Сделал 32 процесса для fastcgi.
Запускаю:
./ab -n 1000 -c 30 http://localhost/fastcgi/test1.pl
И все равно получается много ошибок:

Complete requests:      1000
Failed requests:        745
    (Connect: 0, Length: 745, Exceptions: 0)
Broken pipe errors:     0
Non-2xx responses:      260

> Кстати, а по каким тестам ? И насколько медленее ?

Через ./ab смотрел. В среднем раза в полтора быстрее получается.