Причина, по которой mod_php менее эффективен, чем fastcgi php(php-fpm)

Я вижу, что большинство ответов считают, что mod_php менее эффективен, потому что объем памяти будет больше из-за обслуживания статических файлов, таких как этот.

Но у меня другое мнение, а именно следующее:

На самом деле разделы кода совместно используются процессами fork()ed, поэтому предикат объема памяти не должен выполняться.

Единственная причина, по которой я могу думать, заключается в том, что mod_php не является потокобезопасным, поэтому веб-сервер может создавать подпроцессы только для каждого запроса.

В то время как в режиме fastcgi веб-сервер может повысить производительность за счет трюков с мультиплексированием, тем самым уменьшая fork() накладные расходы.

Одним словом, недостатком mod_php является не его объем памяти, а накладные расходы fork(), но если mod_php может быть потокобезопасным, fork() не понадобится, и это будет наиболее эффективное решение для обслуживания запросов.

Вышесказанное является моим мнением, но не уверенным на 100%.

Это правильно?


fastcgi webserver mod-php
person Je Rog    schedule 13.06.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Разветвление происходит довольно быстро, и установки apache + mod_php по умолчанию также разветвляются. (если не используется рабочий mpm).

Настоящая причина (отчасти) в следующем:

Стандартный mod_php будет иметь достаточно большой процесс, потому что процесс содержит как php, так и все остальные модули apache и т. д. Если php находится в отдельном процессе, процесс php может иметь более короткое время жизни и быстро передать результат обратно в apache, когда PHP будет выполнен.

Другая причина (как вы упомянули) заключается в том, что PHP не затрагивается для запросов, отличных от php.

Тот факт, что вы можете переключиться на рабочий mpm при использовании FastCGI, является просто бонусом; но повышает эффективность.

В общем, с этими типами проектов вы всегда должны стараться сделать как процессы apache, так и php как можно более недолговечными, и их разделение помогает.

Но да… вилки очень быстрые, и в некоторых проектах они могут работать лучше, чем потоки в Linux (без источника, я просто помню, как читал это). Я считаю, что для систем типа веб-сервера системы на основе шаблона Reactor работают даже лучше. NGinx и Varnish — яркие тому примеры.

person Evert    schedule 13.06.2011
comment
Я думаю, что apache и PHP находятся в одном и том же процессе mod_php, а не в отдельном процессе. - person Je Rog; 13.06.2011
comment
Извините, это скорее проблема с плохой формулировкой. Исправляю этот абзац. - person Evert; 13.06.2011
comment
но я все равно не думаю, что причина в этом, так как и в режиме mod_php, и в режиме fastcgi модули php и apache всегда находятся в памяти, единственное отличие состоит в том, что они находятся в разных процессах. То есть в режиме fastcgi рабочие процессы php также стойкий, а не более короткий срок службы. Опять же, объем памяти не является проблемой. - person Je Rog; 13.06.2011
comment
Ну польза заключается в потраченном времени. Несмотря на то, что объем памяти на запрос аналогичен (даже немного больше), для всего запроса требуется намного меньше памяти, и запрос выполняется быстрее. Кроме того, на одного работника Apache требуется меньше работников FastCGI, что также снижает занимаемую площадь. Ваш вопрос может быть слишком расплывчатым... что вы пытаетесь выяснить? - person Evert; 14.06.2011