> В mod_php:
> - можно использовать только prefork, нельзя использовать event, что мне тогда казалось снижает производительность.
> - интерпритатор задействован даже когда отдаётся статика.Я вообще не знаток Apache, но полагаю это всё же некое преувеличение. Вряд ли там задействуется интерпретатор PHP (для чего?) в отдаче статики. Скорее речь идет о том, что он просто всегда загружен в память процесса, даже когда тот просто статику отдает, но при этом не задействуется.
> - на каждый запрос создаётся свой процесс что приводит к повышенному расходу ОЗУ
> - Ошибка в одном PHP-скрипте может положить Apache со всеми виртуальными хостами
Тут опять же логика подсказывает, что в режиме prefork должен падать только тот процесс, что обрабатывает конкретный запрос, приводящий к ошибке, а остальные при этом продолжат обрабатываться.
> В FastCGI этого всего нет, мне тогда он казался однозначно лучше, хотя сейчас погуглив эту тему, пишут что при высокой нагрузке mod_php показывает большую производительность.
> Почему большую, мне не понято. Читая Ваш ответ про MPM event, он должен быть. как минимум, не хуже.
Если говорить именно о динамическом контенте, то добавляя в обработку FastCGI - просто добавляются ещё накладные расходы на передачу данных по этому протоколу.
Что происходит в этом случае:
Один из рабочих потоков Apache вычитывает из сокета соединения запрос, затем парсит его, обрабатывает согласно конфигурации, затем преобразовывает в формат сообщений по протоколу FastCGI и далее записывает запрос в сокет, где на другом конце этого сокета уже запрос в формате FastCGI опять читается из сокета, парсится и передается интерпретатору PHP. Тот формирует ответ и далее всю по цепочке происходит в обратной последовательности с преобразованиями форматов, дополнительными записью и чтением из сокета.
Когда у вас mod_php в prefork работает, то рабочий процесс читает запрос из сокета, парсит его, обрабатывает согласно конфигурации и передает его интерпретатору PHP. Накладных расходов на FastCGI в виде системных вызовов, копирования данных и преобразования форматов тут нет.
Фактически ваша конструкция event MPM и PHP по FastCGI похожа на nginx + php-fpm, с той лишь разницей, что nginx будет эффективнее.
>> Но так ли необходим .htaccess?
>> Даже просто отказ от него с сохранением Apache даст заметный прирост производительности.
>
> Вот это для меня было новостью.
> Я и не предполагал что mod_rewrite так сильно влияет на производительность Apache.
> Я его использую для маршрутизации, тут https://www.opennet.ru/openforum/vsluhforumID3/118512.html#59 привёл пример его использования.
mod_rewrite и .htaccess - сущности ортогональные. Он тут ни при чем. На производительность влияет включение .htaccess файлов, даже если их не будет в каталогах или они будут пустыми. Правила mod_rewrite можно писать и в основной конфигурационный файл Apache, благополучно отключив при этом .htaccess. На производительность mod_rewrite не сильно должен влиять.
> Если кратко, то в DOCUMENT_ROOT у меня есть только 2 объекта к которым можно обращаться
> это директория static и файл index.php
> Если я откажусь от .htaccess мне нужно чтобы на стороне сервера я мог прописать нечто такое.
> - Если URI начинается на /static/ (/static/img/favicon.png) то сервер отдавал статику, даже не пытаясь задействовать php (короче чтобы он не вмешивался и делала что и обычно).
> - Но если запрос НЕ содержит /static/ (/ru/user/1.html) то мне нужно чтобы сервер НЕ изменяя URL (пользователь должен всегда оставаться на том URL с которого он пришёл, если я сам в PHP/JS не решу иначе) вместо попытки обращения к директориям ru и user и поиска там файла 1.html сразу перенаправил запрос на index.php?get=/ru/user/1.html а на стороне PHP я уже сам смогу определить что делать дальше с этим URI из $_GET['get']
>
> Такое можно прописать на Apache или nginx или nginx unit?
> Ну или какие-нибудь иные соображения как можно эффективно организовать ЧПУ маршрутизацию без mod_rewrite?
Можно те же правила mod_rewrite прописать в основном конфиге Apache.
В целом, это достаточно тривиальная конфигурация. В nginx можно делать разными способами. Достаточно настроить пару location'ов (https://nginx.org/r/location/ru) - один для статики, а другой для FastCGI проксирования. А далее, или воспользоваться правилами его собственного модуля rewrite (https://nginx.org/r/rewrite/ru), или, что проще и "прямее", грамотно прописать соответствующие FastCGI переменные. В nginx они просто задаются с помощью директив fastcgi_param (https://nginx.org/r/fastcgi_param/ru), в которых можно указывать комбинации строк и переменных запроса (https://nginx.org/ru/docs/varindex.html). По умолчанию к nginx обычно прилагается файл конфигурации со стандартными значениями: https://hg.nginx.org/nginx/file/tip/conf/fastcgi.conf
В Unit сейчас можно гибко фильтровать запросы и раскидывать их по приложениям или директориям со статикой. Делается это правилами внутреннего роутинга, которые достаточно просты для восприятия: https://unit.nginx.org/configuration/#routes
Что касается rewrite-подобной функциональности, то её пока как таковой нет, но у модуля PHP есть два режима работы:
1. Задана опция "script", содержащая путь к .php скрипту. В этом случае все запросы в приложение будут обрабатываться с помощью данного скрипта. URI запроса будет содержаться в переменной $_SERVER['REQUEST_URI'], просто запущен будет указанный вами в конфигурации скрипт, а не то что пришло в запросе.
2. Опция не "script" не задана. Тогда запускается тот скрипт, на который указывает URI запроса. Также если URI содержит так называемый компонент PATH_INFO (например /index.php/some/path), то Unit отрежет путь после .php (в данном случае "/some/path") и поместит его в $_SERVER['PATH_INFO'].
