d> А можно вопрос - зачем spawn-fcgi? Или я чего-то непонял - но ведь
d> если собрать php --width-fastcgi, он и сам висит, порт слушает,
d> и nginx напрямую с ним работает
Можно, пробовал, но:
1. было два неприятных глюка:
а. При хоть сколько серьезной нагрузке время отклика пхп становилось
непомерно большим(скрипт обрабатывался быстро, но перед этим видимо
стоял в очереди секунд по 10-40).
б. PHP почему-то любил падать в кору после каждых N скриптов, вне
зависимости от нагрузки(ночью редко, днем постоянно), nginx при этом
отдавал юзерам Bad Gateway, у меня откликов от юзеров было много,
хотя PHP и перезапускался в цикле).
со spawn-fcgi этих проблем не возникает, т.к. демонов стартует
несколько и они почему-то толи не падают, толи запрос от упавшего
уходит на работающий.
PHP можно запускать так:
PHP_FCGI_CHILDREN=4 PHP_FCGI_MAX_REQUESTS=100000 php -b port
тогда он запустит 4 процесса и будет выходить после 100000 запросов.
Хотя у меня тоже сложилось впечатление, что с spawn-fcgi работать будет
стабильнее.
2. коннекты можно мапить только на порт. spawn-fcgi умеет сокеты.
А это можно вылечить с помощью прилагаемого патча.
Игорь Сысоев
--- sapi/cgi/cgi_main.c Thu Jan 20 16:39:51 2005
+++ sapi/cgi/cgi_main.c Thu Jan 20 16:42:18 2005
@@ -1145,7 +1145,7 @@
* path (it's what the fastcgi library expects)
*/
- if (strchr(bindpath, ':') == NULL) {
+ if (strchr(bindpath, ':') == NULL && strchr(bindpath,'/') ==
NULL) {
char *tmp;
tmp = malloc(strlen(bindpath) + 2);
