nginx и Perl: FastCGI против обратного прокси (PSGI / Starman) - PullRequest
Новая
       31

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

19 голосов
/ 23 октября 2010

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

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

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

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

Точно так же конфигурация nginx для любого варианта очень похожа.

Так почему бы вы выбрали один из других?

Ответы [ 2 ]

15 голосов
/ 05 марта 2011

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

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

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

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

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

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

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

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

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

0 голосов
/ 17 декабря 2010

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

...