[MakaBooka]

Таким образом, использование FastCGI является более безопасным, как с точки зрения прав доступа »

Сферично и вакуумно.

mod_php, в свою очередь, имеет некоторое увеличение быстродействия при большой (в тысячи соединений) нагрузке на сайт. »

Когда не включает течку, да.

Если только ваши сайти будут на сервере - можно как модуль Если будут несколько юзеров - FastCGI »

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

Из практического опыта: nginx прекрасно отдаёт статику. php-fpm решает вопрос с течкой php. nginx + php_fpm сложнее в отладке сбоев. nginx + php-fpm не имеет .htaccess. Если это не проблема - можно использовать php-fpm + nginx.
Если сайт относится к тяжело нагруженым, то

На VPS будут только мои сайты »

...VPS не подходит делается индивидуальная конструкция.
Опять же нужно помнить, что у апача несколько вариантов работы: prefork, worker.... так же апач может работать как реверс-прокси и кэшировать статику (вариант работы апач-под апачем) или это можно поручить тому же nginx.

Короче целый просто для разных конструкций в зависимости от нагрузки, прямизны рук и вкусовщины. На мой взгляд связка nginx+php-fpm очень даже неплоха, как для скромных сайтов, так и для тяжелонагруженных.

В целом конечно нужно делать, мерить, сравнивать, профилировать.

[CyraxZ]

Для Apache много всяких правил и настроек сконфигурировано и отшлифовано. тяжеловато будет на nginx переносить.
Пока остановился на Apache mpm-event + php-fcgi.

[CyraxZ]

Вопрос в том, работает ли Apache в режиме event вместе с php-fcgi ?

[CyraxZ]

2 веских довода в пользу mod_fcgi (вместо mod_php):
1. Благодаря suexec возможно запускать php-скрипты от имени конкретного пользователя => скрипты не получат доступ к чужим и системным файлам

2. php_mod не работает с Apache в режимах mpm-worker и mpm-event:
https://www.garron.me/en/blog/apache...efork-php.html

[CyraxZ]

Вот что пишут на php.net:
Почему лучше не пользоваться Apache2 с многопоточным "MPM" (event, worker) в промышленной эксплуатации?

PHP подобен связующему звену. Он полезен для создания хороших веб-приложений путём объединения разрозненных сторонних библиотек в единое целое, через использование интуитивно понятного и простого для изучения языкового интерфейса. Гибкость и сила PHP основана на стабильности и устойчивости платформы, на которой он работает. Чтобы всё работало, нужна рабочая операционная система, рабочий веб-сервер и рабочие сторонние библиотеки. Но когда хоть что-либо из них перестаёт работать - PHP нуждается в способах быстрого определения причины неполадки и её устранения. И когда Вы усложняете базовый фреймворк тем, что не изолируете исполняемые потоки и сегменты памяти, и не предоставляете потокам отдельных изолированных "песочниц" - ослабляется вся PHP-система. Если Вы пожелаете использовать многопоточный "MPM" - ознакомьтесь с конфигурацией "FastCGI", согласно которой PHP работает в собственном пространстве памяти.

P.S. Apache 2.2 по умолчанию работает в режиме prefork (на уровне компиляции), Apache 2.4 - в режиме event (на уровне модуля).

[MakaBooka]

Но когда хоть что-либо из них перестаёт работать »

С чего бы?

[CyraxZ]

1. Благодаря suexec возможно запускать php-скрипты от имени конкретного пользователя => скрипты не получат доступ к чужим и системным файлам

Если все сайты принадлежат одному пользователю, то с версии Apache 2.2.10 на Unix-системах можно обойтись и без suexec: статический модуль modx_unixd позволяет указывать пользователя и группу, под которыми будут запускаться форки.

Таким образом, единственным железным аргументом в пользу mod_fcgid остаётся неработоспособность модуля mod_php в режимах mpm_worker и mpm_event. При установке libapache2-mod-phpX Apache принудительно переводится в режим mpm_prefork.

С чего бы?

Мутная у них аргументация...