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

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

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

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

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

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

Так почему бы вам выбрать один над другим?


nginx reverse-proxy fastcgi perl plack
person aaa90210    schedule 23.10.2010    source источник

Ответы (2)


arrow_upward
16
arrow_downward

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

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

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

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

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

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

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

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

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

person jpetazzo    schedule 04.03.2011
comment
Исходный IP-адрес клиента передается в заголовке X-Forwarded-For, а исходный заголовок Host передается в заголовке X-Forwarded-Host, поэтому первые два недостатка не важны. - person marpetr; 23.02.2013
comment
+1 спасибо за сравнение. Поскольку можно запустить основной процесс для управления внутренними процессами и потоками, пункт 3 не является проблемой. Вы подняли интересный вопрос о Zope и способе узнать исходный IP-адрес клиента и имя хоста для создания действительных URL-адресов. - person Viet; 28.05.2013

arrow_upward
0
arrow_downward

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

person mdom    schedule 17.12.2010