2010/5/31 iWarior <nginx-forum@nginx.us>:
> [i]Я сказал в первом письме. Нужно запустить несколько процессов php-cgi.[/i]
>
> Это т.е. для более-менее посещаемых проектов, желающих nginx+php(fast-cgi) хозяйство выглядит так:
>
> 1) Создаем 100-150 процессов, занимая 100-150 портов.
> 2) Потом в конфиге через ngx_http_upstream группируем всё это дело и по таймаутам оно типа должно по очереди перебирать эти php-cgi ?
>
> Я правильно понял Ваше предложение понял? Если да, то это мало пригодно для реальной жизни... =(

По поводу количества процессов: скорее хватит 20-30 (и не забываем
кешировать ответы бекендов), хотя, конечно, это сильно зависит от
нагрузки. На linux/freebsd значительная часть памяти у них всех будет
общая. Что ещё вас смущает в количестве? На windows да, это мало
пригодно. Там нужно использовать потоки, и опять же, память будет
общая.

По поводу портов: опять же, на unix ОС можно использовать UNIX сокеты
— они файлы и "портов не занимают". Ну и допустим 100-150 портов
занимают. Из 64 тысяч занято 150. Не велика нагрузка на пространство
портов.

Про upstream всё правильно, да. Таймауты тут не причём, просто по
очереди перебираются бекенды, да. Есть модуль fair upstream, который
более хитро выбирает бекенды, чтоб они равномерно были загружены.

> [i]Апач справится лучше, и настроить его будет проще. Хватит уже любить
> самого себя в мозг :)[/i]
>
> мне просто отчего-то кажется, что php-cgi должен одновременно кушать несколько заданий, это ж бред какой-то, что он выполняет только одно задание, зачем он тогда такой нужен, да ещё висящий в памяти и занимающий порт. На fast этот cgi не похож =)
>

Fast тут заключается в том, что, в отличие от традиционного CGI, на
каждый запрос не запускается новый процесс, а используется ранее
запущенный. Это ускоряет обработку запроса, отсюда и название Fast.

ParallelCGI никто не обещал.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru