nginx+fastcgi vs nginx+apache+mod_php?

[Wicked]

nginx+fastcgi vs nginx+apache+mod_php?

Что-то я думал, читал, смотрел слайды, и так до конца не понял, чем же связка nginx+fastcgi лучше (и лучше ли?), чем проксирующий фронт на nginx + бэк в виде апача (1.3, 2.х) с mod_php в условиях сильной нагрузки и необходимости масштабироваться? Может кто-нибудь кинуть ссылкой и/или доходчиво разложить по полочкам?

За основу распределения типов нагрузки предлагаю взять абстрактную социальную сеть.

 

[MiksIr]

Если во второй схеме отдавать статику nginx-ом, а не проксировать на апач, то фактически ничем не отличается, за исключением освобожденной от собственно апача памяти. Просто апач тут становится ненужным звеном, особо если будет доделан php-fpm в области менеджера детей.

 

[Wicked]

Если во второй схеме отдавать статику nginx-ом

разумеется.

Про память понятно, это даже в русской википедии упоминается:

В отличие от иных решений только FastCGI процесс должен находиться в кластере, а не целый web-сервер. Это позволяет использовать FastCGI процессу больше резурсов чем, например, load-balancer+apache+mod_php.

Мне вот еще стало интересно следующее...
там же, в википедии написано следующее:

Instead of creating a new process for every request, FastCGI can use a single persistent process which handles many requests over its lifetime. Processing of multiple requests simultaneously is achieved either by using a single connection with internal multiplexing (ie. multiple requests over a single connection) and/or by using multiple connections.

Я правильно понимаю, что тут подразумевается одновременная обработка процессом нескольких запросов? Это, случаем, не аналог mpm worker в апаче, который не рекомендуется использовать с пхп?

PS: я пока сам не совсем понимаю, о чем спрашиваю, так что сильно не пинайте .-)

 

[MiksIr]

Давайте набросаю теории... возможно, все это Вам известно, но хуже не будет.
FastCGI - это по сути протокол, расширяющий CGI. Его суть заключается в том, что в отличии от CGI схемы, где каждый запрос пораждает запуск исполняемого файла, в FastCGI запрос пробрасывается на менеджер таких запросов, который берет на себя управление - что запускать.
Например, можно реализовать схему, когда менеджер FastCGI запросов, на каждый такой запрос будет запускать затребованный исполняемый файл и выдавать его ответ - т.е. по сути ничем не отличаться от обычного CGI. Конечно, так никто не использует FastCGI ибо...
Ибо из-за удобной схемы получения запросов можно сделать так, что бы приложение один раз запустилось, а потом только принимало запросы от FastCGI, обсчитывало их и выдавало ответ. Одно "но" - приложение должно уметь работать в таком режиме.
А дальше, получив такое приложение мы сталкиваемся с задачами "параллельности" исполнения запросов, которые ничем не отличаются от подобных задач в веб-серверах.
В FastCGI есть понятие "менеджера" запросов. По сути, это та часть кода, которая занимается акцептом соединения с клиента и передача полученного запроса той части кода, что сможет запрос обсчитать и выдать ответ. Выделяю я это потому что такие менеджеры могут быть отдельны от приложения, например, PHP можно запускать в FastCGI режиме как со встроенным менеджером запросов, так и с внешним (в пакете lighthttp есть.. кажется spawn-fcgi). Патч php-fpm - по сути переписанный встроенный в PHP менеджер запросов, ибо оригинальный встроенный обладает определенной нестабильностью.
Итак, FastCGI дает возможности, а как их реализует конкретное приложение - его дело.
Если говорить о ПХП, то там схема prefork - форкаются несколько детей, и запросы распределяются между ними. prefork статичный - т.е. количество форкнутых детей не меняется (php-fpm обещает это изменить).