Ответ
FastCGI (Fast Common Gateway Interface) — это бинарный протокол для эффективного взаимодействия веб-сервера (например, Nginx или Apache) с внешними прикладными процессами, обрабатывающими динамический контент (PHP, Python).
Решает проблему классического CGI: Вместо того чтобы запускать и завершать процесс интерпретатора (например, PHP) для каждого HTTP-запроса (что очень накладно), FastCGI использует долгоживущие процессы-воркеры. Веб-сервер просто передаёт запрос в свободный рабочий процесс через быстрый сокет или TCP-соединение.
PHP-FPM (FastCGI Process Manager) — это реализация FastCGI-протокола специально для PHP. Это демон, который управляет пулом (pool) PHP-процессов.
Как это работает в связке Nginx + PHP-FPM:
- Nginx получает запрос к
index.php. - Согласно конфигурации, Nginx передаёт запрос PHP-FPM (через Unix-сокет или TCP).
- PHP-FPM выбирает свободный процесс из пула, передаёт ему данные запроса и путь к скрипту.
- PHP-процесс выполняет скрипт и возвращает результат (HTML/JSON) PHP-FPM, который передаёт его обратно Nginx.
- Nginx отправляет ответ клиенту. PHP-процесс остаётся живым и готов к следующему запросу.
Пример конфигурации Nginx для передачи запросов PHP-FPM:
server {
location ~ .php$ {
# Передаём запрос бэкенду по Unix-сокету
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
# Сообщаем бэкенду, какой файл выполнять
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# Подключаем стандартный набор FastCGI-параметров
include fastcgi_params;
}
}
Ключевые преимущества: высокая производительность, стабильное потребление памяти, возможность отдельного управления PHP-процессами (перезапуск, настройка пулов для разных сайтов).
Ответ 18+ 🔞
Ну слушай, объясню на пальцах, а то в этих мануалах мозги выносят, ёпта. FastCGI — это типа как налаженный канал связи между веб-сервером (ну, Nginx там) и твоим скриптом на PHP. Представь себе, что раньше было так: на каждый чих, на каждый запрос к сайту, сервер порождал нового PHP-процесса, тот отрабатывал и накрывался медным тазом. Овердохуища процессов, ресурсы жрал как не в себя — пиздец, а не эффективность.
А FastCGI приходит и говорит: «Да похуй, зачем каждый раз рожать и убивать? Давайте заведём долгоживущих работяг!». То есть, создаётся пул этих самых PHP-воркеров, которые сидят себе тихо и ждут работы. Nginx, когда ему нужно выполнить index.php, не парится, а просто кидает задание в сокет свободному работяге из этого пула. Тот всё делает, отдаёт результат и снова ждёт. Красота, да? Экономия — ебать колотить.
А PHP-FPM — это, бля, уже конкретная реализация этой идеи для PHP. Это такой демон-управленец, который эти самые пулы процессов и содержит. Его можно тонко настраивать: сколько воркеров запустить, как они будут перезапускаться, если сдохнут — в общем, полный контроль.
Как это в связке Nginx + PHP-FPM работает, на примере:
- Какой-то чувак в браузере тыкает на ссылку, ведущую на
page.php. - Nginx ловит этот запрос, смотрит конфиг и понимает: «А, это ж PHP, мне тут делать нечего, это к специалисту».
- Он быстренько, через Unix-сокет (или по сети, если надо), пересылает все детали запроса PHP-FPM. Типа: «На, братан, вот тебе скрипт, вот данные от пользователя — разберись».
- PHP-FPM смотрит в свой пул, видит свободного PHP-работягу, пихает ему задание. Тот, сука, выполняет скрипт, генерит HTML.
- Готовый HTML возвращается по цепочке обратно: работяга -> FPM -> Nginx -> пользователю. И работяга не умирает, а остаётся жить дальше, ждать новую задачу. Гениально и просто, волнение ебать!
Вот тебе кусок конфига Nginx, который эту магию и делает. Смотри, тут главное — правильно указать, куда стучаться к FPM:
server {
location ~ .php$ {
# Вот эта строка — святая святых. Говорит Nginx'у: "Отправляй все запросы на .php вот по этому сокету к PHP-FPM"
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
# А это чтобы FPM понял, какой именно файл ему нужно выполнить
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# Подключаем стандартные параметры, чтобы ничего не забыть
include fastcgi_params;
}
}
Итог, чувак: Производительность — огонь, память не уплывает вникуда, управлять процессами — одно удовольствие. Вместо того чтобы каждый раз заново изобретать велосипед, система использует готовых, разогретых специалистов. Хуй с горы, а не архитектура!