Добрый день.

А для чего у вас php c Apache через FastCGI работает вместо mod_php? Есть конечно кейсы в которых даже с Apache такой вариант необходим, но FastCGI имеет свои накладные расходы и тут не добавляет эффективности.

Если так сильно нужен .htaccess, то я бы рассмотрел связку nginx + Apache c mod_php. Но так ли необходим .htaccess? Даже просто отказ от него с сохранением Apache даст заметный прирост производительности. Дело в том, что для его работы приходится на каждый запрос сканировать все директории по пути на предмет наличия в них .htaccess файлов, даже если их нет. Это порождает огромное количество дополнительных системных вызовов на каждый запрос и, как следствие, сильно увеличивает накладные расходы. Последующий их парсинг и интерпретация - это пустяки на этом фоне. Да и вообще хранение конфигурации внутри директории, которая раздается в интернет - идея сомнительная.

Но, допустим, что по какой-то причине отказаться от .htaccess вы не можете. Тогда переход на mod_php уменьшил бы накладные расходы на обработку PHP в Apache, а nginx впереди освободил бы его от взаимодействия с медленной сетью и раздачи статики.

Идея тут такая. Поскольку nginx работает с соединениями асинхронно и не блокируясь, то вся обработка происходит в рамках небольшого количества процессов, каждый из которых способен обрабатывать сотни тысяч соединений с минимумом накладных расходов. Дело не сколько в скорости, сколько в масштабируемости при росте нагрузки. Процессы с интерпретатором php дорогие и каждый из них способен обрабатывать только один запрос в момент времени от начала и до конца. Иметь сотни тысяч таких процессов будет очень накладно, как по памяти, так и с точки зрения расходов на переключение контекстов. Поэтому их количество обычно небольшое и задача nginx сделать так, чтобы они работали максимально эффективно, тратя время только на интерпретацию кода, а не сетевые взаимодействия. Поэтому nginx ставят рядом на одну машину. Он работает с медленными соединениями клиентов (а они все медленные по сравнению с локальными процессами) не тратя много ресурсов на обработку. Как только он получил полностью запрос, то максимально быстро передает его в Apache или php-fpm, тот его обрабатывает, и nginx дальше максимально быстро забирает ответ, освобождая процесс c PHP для следующего запроса. Кроме того, все запросы к статике также обрабатываются внутри nginx и не занимая дорогостоящих процессов с php.

У Apache есть event MPM и некоторые заявляют, что это то же самое, что nginx. Но это лукавство, т.к. событийно там обрабатываются только keep-alive соединения в момент простоя. Такие соединения больше не занимают отдельных потоков, но как только начинается обработка запроса, то тут же Apache деградирует до модели с одним потоком на каждый запрос. Да, простаивающие соединения в Apache теперь примерно такие же дешевые, как в nginx, но не более того. Под нагрузкой всё это также схлопывается.

TLS 0-RTT nginx поддерживает, см. директиву конфигурации ssl_early_data (https://nginx.org/r/ssl_early_data/ru).

HTTP/3 запланирован в 1.17.x и точно появится в течение ближайшего года, может быть даже быстрее, полгода.

Если от .htaccess всё же можно отказаться, то замена Apache/mod-php на php-fpm в связке с nginx даст более простой и специализированный инструмент, проще конфигурацию PHP на мой взгляд. Но если в Apache повыключать всё лишнее, особенно .htaccess, то какой-то заметного превосходства по производительности у nginx+php-fpm перед nginx+apache/mod_php не будет. Тут скорее вопрос удобства и простоты.

Наиболее удобным и оптимальным со всех стороны решением мог бы стать Unit. Он делает то, что делает nginx, эффективно работает с соединениями и при этом имеет минимум накладных расходов на обмен данными с процессами интерпретатора. Но, к сожалению, 0-RTT в нем пока ещё нет, как и HTTP/3. И вообще конфигурация TLS в этом месте на данный момент убогая. В результате его пока что также придется использовать за nginx. И часть преимуществ из-за этого теряется. Тем не менее, даже в таком варианте можно начинать пробовать с целью познакомиться, поэкспериментировать и возможно в будущем отказаться от nginx, оставив один лишь Unit. Из плюшек nginx + Unit перед nginx + php-fpm, которые можно получить сразу - это динамическая конфигурация. В частности будет возможность изменять параметры php.ini и управлять процессами без перезагрузки всего Unit-а и потери запросов. Чтобы изменения в конфигурации php-fpm вступили в силу, его нужно полностью перезагрузить, даже если изменения касаются всего лишь одного пула. Это может быть  очень накладно, если пулов много, и создает момент времени, когда php-fpm будет не способен принимать соединения. Кроме того, если вы хотите одновременно использовать несколько версий интерпретатора php, то вам необходимо несколько отдельных php-fpm и раскидывать с помощью nginx между ними запросы. Unit может одновременно работать с несколькими разными версиями php, можно раскидать по ним разные проекты, либо протестировать то же приложение, но с другой версией, а затем без потерь переключить основной поток запросов на новую версию. Вариантов тут много, архитектура Unit-а позволяет любые комбинации и множество паттернов использования, кому как нравится. Кроме того, в новой версии у нас появилась изоляция за счет Linux namespaces и она дальше будет прогрессировать, обрастая новыми возможностями. Можно будет какой-нибудь вордпресс заизолировать, как в контейнере, но без необходимости связываться с Docker-ом. Ничего не имею против последнего, но многие очень приветствуют такую возможность в Unit-е.