Re[2]: Популяризация nginx среди нерусскоязычного насе ления :-)

[Vitaly Puzrin <vitaly@xxxxxxxxxxx>]

>>Тогда сам смысл FastCGI теряется.. Да и не спасет это ни от чего при
>>большой нагрузке.
>>  
>>
E> Ну почему? Сайтов может быть много, но не все же одновременно посещаются?
E> Тем более сам по себе fascgi работает так, что периодически надо 
E> перезапускаться, иначе может скапливаться "мусор" в памяти. Во всяком 
E> случае так в спецификации и так в родном php-шном менеджере процессов.
E> То есть перезапускать все равно надо. Тогда вопрос: зачем держать 
E> процессы когда они не нужны?

E> С динамическим fastcgi получается очень логичная модель:
E> для каждого сайта свои процессы от своего пользователя. Когда сайт 
E> отдыхает, процессы тоже отдыхают. Как только кто-то зашел на сайт тут же
E> запускается fcgi сервер и начинает обабатывать запросы. После последнего
E> запроса он еще какое-то время висит в памяти, после убивается.

E> Вот если бы nginx имел менеджер процессов и мог запускать fastcgi 
E> сервера, то это было бы шикарно.
E> В этом случае не требовалось бы промежуточное звено в виде апача. Можно
E> было бы снизить потребление памяти и увеличить скорость работы.

E> Скажите, Игорь - возможно ли добавить к fastcgi модулю менеджер процессов?


E> Евгений

По-моему вы что-то путаете. В комплекте с lighttpd идет утилита для
запуска php в режиме fastcgi, которая делает кучу всяких побочных
полезных действий. В конфиге можно указывать количество запущенных
процессов и периодичность перезапуска. FCGI сервер стартует при
запуске системы, стандартными способами, теми же что и остальные
демоны, и потом работает вроде бы стабильно. Возможные утечки памяти
ликвидируются при автоматическом перезапуске.

Кроме того, запуск php в режиме FCGI занимает несколько десятков
секунд, если я не ошибаюсь. Поэтому о динамике тут говорить сложно.
Плюс отдельный пул процессов для каждого сайта довольно сильно
подрежет преимущества концепции FCGI.