> [i]Так надо было именно с этой проблемой и обращаться, чтобы
> вам посоветовали как её решить.[/i]
>
> у меня стояло тогда и сейчас:
>
> [code]
> fastcgi_next_upstream timeout;
> fastcgi_connect_timeout 1;
> [/code]
>

error из fastcgi_next_upstream, это вы, конечно, зря убрали. Попробуйте с ним.

> nginx отправляет запросы на бекенды по очереди 1-ый на 1-ый, 2-ой на 2-ой, 3-ий на 1-ый, даже если он занят, переброска на 2-ой бекенд не происходит. Т.е. таймаут не срабатывает, как я понимаю, отсюда я делаю вывод, что nginx не считает занятый php-cgi не отвечающим, т.к. последний видать всё же отвечает, поэтому и не переходит к следующему.

Да, видать всё же php-cgi принимает соединение. Может быть, он
принудительно запускает ровно одного потомка, а родитель продолжает
принимает конекты. Очень странное решение они там приняли, если это
так. Значит, поможет только внешняя запускалка. Ну ещё стоит
попробовать php-fpm, может там тоже решена эта проблема.

>  [i]А скоропостижные выводы, типа "так
> ничего не выйдет", вашу задачу решить не поможет.[/i]
>
> надеюсь, что я что-то упустил и связка nginx + несколько php-cgi всё же настраиваема без костыля, что я нашёл ниже :)
>
> ---
>
> В поисках решения этой проблемы на сайте Lighttpd нашёлся порт (не офиц.) их spawn-fcgi под Windows (обсуждалось здесь http://redmine.lighttpd.net/boards/2/topics/686). Порт оказался вполне рабочий и, вроде бы, стабильно работает с nginx, чему я, конечно, крайне рад.
>

Это не костыль, а вполне хороший способ держать несколько процессов
php. Миллионы сайтов работают именно с spawn-fcgi.

php-fpm, Apache — другие хорошие способы.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru