FastCGI устарел, но по-прежнему кажется, что в некоторых случаях это должен быть правильный ответ.
Похоже, что предпочтительным развертыванием веб-приложений Perl/Catalyst является FastCGI.
FastCGI был популярен среди Rails, но, похоже, больше не будет. (Почему?)
Мир Java, похоже, не имеет ничего общего с FastCGI. Что-то вроде Tomcat лучше, чем Apache + FastCGI?
Является ли выбор FastCGI еще хорошей идеей или просто затяжной технологией?
Тед
Поскольку это зависит от ваших настроек и требований, я позволю "Является ли X правильным ответом?" вам решать. Однако, глядя на разные архитектуры, вы можете составить список вопросов, которые необходимо задать, чтобы определить, является ли он правильным ответом при определенных обстоятельствах.
Вопросы, которые вы хотите задать, обычно связаны с безопасностью и гибкостью. Для обеспечения безопасности вы должны следовать принципу наименьших привилегий . Для гибкости вы захотите узнать, можете ли вы запускать несколько фреймворков, несколько версий фреймворка и как легко вы можете делегировать работу другим задачам.
Для простого веб-интерфейса для приложения с поддержкой базы данных важны не все эти вопросы. Вам также нужно иметь в виду, что некоторые рекомендации не имеют никакого отношения к тому, что описано здесь. Многие веб-фреймворки рекомендуют любую архитектуру проще всего настроить с помощью своей инфраструктуры. Они делают это, потому что это помогает получать новые пользователи с минимальной суетой и без наводнения списка рассылки. Кроме того, сообщество Java имеет тенденцию придерживаться общего знаменателя, а не в полной мере использовать платформу под рукой, поэтому они часто рекомендуют решение всей Java.
С точки зрения чистой производительности один процесс (возможно, с потоковой передачей) со встроенной инфраструктурой, вероятно, дает большую производительность, поскольку он уменьшает большинство коммуникационных издержек между тем, что получает запрос, и тем, что производит ответ.
Безопасность: один процесс должен иметь все разрешения, необходимые для выполнения каждой отдельной задачи, которую он передает. В простых приложениях это может не быть проблемой. Однако, возможно, вы можете обслуживать несколько сервисов.
Гибкость: возможно, не может запускаться несколько версий одной и той же структуры (например, для разных частей вашего сайта требуются разные версии Java, Rails, Python и т.д.). Более того, изменение вашей настройки для работы на разных машинах становится болезненным (менее сложным при разделении на виртуальные хосты).
В соответствии с моделью CGI вы должны заплатить цену за создание нового процесса для каждого запроса. Даже на машинах UNIX, где нерестование процесса считается дешевым, 600 запросов в секунду убьют ваш сервер, если вы создадите процесс для каждого.
Безопасность: для создания дочерних процессов под разными учетными записями пользователей ваш шлюз, вероятно, работает с довольно высокими привилегиями.
Гибкость: дополнительная гибкость для нескольких фреймворков, нескольких версий, нескольких языков, но вы все еще застряли на одной машине.
Метод FastCGI/SCGI попытался решить проблему управления процессом CGI чистым способом. Просто продолжайте процесс. Попросите шлюз поговорить с этим процессом, чтобы выполнить запрос.
Безопасность. Поскольку шлюз не создает процессы, которые обслуживают запросы, шлюз может работать с гораздо меньшими привилегиями. Фактически, если он служит только шлюзом и не выполняет никакой работы, он может работать с почти любыми привилегиями вообще.
Гибкость: вы получаете еще большую гибкость, чем модель CGI, потому что вы можете перенаправить запрос на любую машину в сети.
Мне нравится FastCGI, потому что он дает мне высокую гибкость по цене (т.е. запрос, отправленный через сокет), я могу позволить себе заплатить. Это не моя полная работа для администрирования систем. Я не разрабатываю все приложения, которые я размещаю. Это означает, что я ищу самое простое решение для хостинга, что бы я ни пытался организовать. FastCGI достаточно популярен для поддержки основных веб-серверов и популярных веб-фреймворков. Добавление другого приложения обычно просто сводится к установке и отображению нужного URL-адреса приложения через FastCGI.