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
И все равно получается много ошибок:
Complete requests: 1000
Failed requests: 745
(Connect: 0, Length: 745, Exceptions: 0)
Broken pipe errors: 0
Non-2xx responses: 260
Кстати, а по каким тестам ? И насколько медленее ?
Через ./ab смотрел. В среднем раза в полтора быстрее получается.
