Nginx и Perl: FastCGI против обратного прокси (PSGI/Starman)

Очень популярный выбор для работы веб-приложений Perl в наши дни, по-видимому, находится за прокси-серверами nginx для прокси-сервера либо для FastCGI-демона, либо для веб-сервера с поддержкой PSGI (например, Starman).

Было много вопросов относительно того, почему это можно сделать вообще (например, Зачем использовать nginx с Catalyst/Plack/Starman?) и ответы кажутся применимыми в обоих случаях (например, разрешить nginx обслуживать статический контент, простой перезапуск сервера приложений, балансировку нагрузки и т.д.).

Однако меня особенно интересуют плюсы и минусы использования FastCGI и обратного прокси-подхода. Похоже, что Starman широко считается самым быстрым и лучшим приложением Perl PSGI/веб-сервером, и я изо всех сил стараюсь увидеть все преимущества использования FastCGI. Оба подхода, похоже, поддерживают:

  • Сокеты домена UNIX, а также сокеты TCP
  • серверы стиля fork/process manager, а также неблокирующие серверы на основе событий (например, AnyEvent).
  • Обработка сигналов/изящный перезапуск.
  • PSGI

Аналогично, конфигурация nginx для любой опции очень похожа.

Итак, почему вы выбрали один из них?

Ответы

Ответ 1

Настройка обратного прокси-сервера (например, пересылка HTTP-запросов nginx в Starman) имеет следующие преимущества:

  • вещи немного легче отлаживать, поскольку вы можете легко удалять сервер бэкэнд,

  • если вам нужно масштабировать свой серверный сервер, вы можете легко использовать что-то вроде фунта /haproxy между HTTP-интерфейсом (статическим сервисом) и вашими бэкэндами (Zope часто развертывается таким образом);

  • он может быть приятным приятелем, если вы также используете какой-то внешний обратный, кеширующий, обратный прокси (например, Varnish или Squid), поскольку он позволяет легко обойти его.

Однако он имеет следующие недостатки:

  • сервер базы данных должен выяснить реальный IP-адрес, поскольку все, что он увидит, - это адрес сервера интерфейса (обычно локальный); есть почти простой способ узнать IP-адрес клиента в заголовках HTTP, но что-то дополнительное, чтобы выяснить,

  • сервер backend обычно не знает HTTP-заголовок orignal "Host:" и, следовательно, не может автоматически генерировать абсолютный URL-адрес для локального ресурса; Zope обращается к этому со специальными URL-адресами, чтобы вставлять исходный протокол, хост и порт в запрос к серверу, но это то, что вам не нужно делать с FastCGI/Plack/...;

  • интерфейс не может автоматически запускать бэкэнд-процессы, как, например, с FastCGI.

Выберите свои любимые плюсы и минусы и сделайте свой выбор, я думаю; -)

Ответ 2

HTTP хорошо понимается большинством системных администраторов и легко отлаживается. Там почти всегда есть какой-то обратный прокси-сервер, который уже развернут, поэтому кусок пирога просто добавляет еще одну конфигурационную строфу в свою конфигурацию, чтобы запустить приложение за несколько секунд. Никогда не проверял разницу в скорости с обоими настройками, но, с другой стороны, у меня никогда не было проблем в этой области, так что это не может быть так плохо.