ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 смотрел. В среднем раза в полтора быстрее получается.





 




Copyright © Lexa Software, 1996-2009.