nginx和Perl:FastCGI与反向代理(PSGI/Starman) [英] nginx and Perl: FastCGI vs reverse proxy (PSGI/Starman)

问题描述

这些天来，运行Perl Web应用程序的一个非常流行的选择似乎是在Nginx Web服务器将请求代理到FastCGI守护程序或启用PSGI的Web服务器(例如Starman)之后.

A very popular choice for running Perl web applications these days seems to be behind a nginx webserver proxying requests to either a FastCGI daemon or a PSGI enabled webserver (e.g. Starman).

关于为什么人们通常会这样做有很多问题(例如

There have been lots of question as to why one would do this in general (e.g. Why use nginx with Catalyst/Plack/Starman?) and the answers seem to apply in both cases (e.g. allow nginx to serve static content, easy restart of application server, load balancing, etc.)

但是，我对使用FastCGI与反向代理方法的优缺点特别感兴趣.似乎Starman被公认为是那里最快，最好的Perl PSGI应用程序/Web服务器，而我正在努力地看到使用FastCGI的所有优势.两种方法似乎都支持:

However, I am specifically interested in the pros/cons of using FastCGI vs a reverse-proxy approach. It seems that Starman is widely considered to be the fastest and best Perl PSGI application/web server out there, and I am struggling to see any advantages to using FastCGI at all. Both approaches seem to support:

• UNIX域套接字以及TCP套接字
• fork/process manager样式的服务器以及基于事件的非阻塞(例如AnyEvent)服务器.
• 信号处理/正常重启
• PSGI

类似地，这两个选项的nginx配置都非常相似.

Similarly, nginx configuration for either option is very similar.

那为什么要选择一个呢?

So why you would choose one over the other?

推荐答案

反向代理设置(例如nginx将HTTP请求转发给Starman)具有以下优点:

A reverse proxy setup (e.g. nginx forwarding HTTP requests to Starman) has the following advantages:

• 事物调试起来容易一些，因为您可以轻松地直接访问后端服务器；

• things are a bit easier to debug, since you can easily hit directly the backend server;

如果您需要扩展后端服务器，则可以轻松地在前端HTTP(静态服务)HTTP和后端之间使用磅/代理之类的东西(Zope通常这样部署)；

if you need to scale your backend server, you can easily use something like pound/haproxy between the frontend (static-serving) HTTP and your backends (Zope is often deployed like that);

如果您还使用某种面向外部的，缓存，反向代理(例如Varnish或Squid)，它可能是一个不错的伙伴，因为它可以非常容易地绕过它.

it can be a nice sidekick if you are also using some kind of outward-facing, caching, reverse proxy (like Varnish or Squid) since it allows to bypass it very easily.

但是，它具有以下缺点:

However, it has the following downsides:

后端服务器必须找出真正的原始IP，因为它将看到的只是前端服务器地址(通常是localhost)；几乎可以通过一种简单的方法在HTTP标头中找到客户端IP地址，但这还需要解决其他问题；

• the backend server has to figure out the real originating IP, since all it will see is the frontend server address (generally localhost); there is almost an easy way to find out the client IP address in the HTTP headers, but that's something extra to figure out;

后端服务器通常不知道原始的"Host:" HTTP标头，因此无法自动生成指向本地资源的绝对URL. Zope使用特殊的URL来解决此问题，以将原始协议，主机和端口嵌入到后端的请求中，但这与FastCGI/Plack/...无关.

the backend server does not generally know the orignal "Host:" HTTP header, and therefore, cannot automatically generated an absolute URL to a local resource; Zope addresses this with special URLs to embed the original protocol, host and port in the request to the backend, but it's something you don't have to do with FastCGI/Plack/...;

前端无法像在FastCGI中那样自动生成后端进程.

the frontend cannot automatically spawn backend processes, like it could do with FastCGI for instance.

选择您喜欢的利弊，然后做出选择；-)

Pick your favourites pros/cons and make your choice, I guess ;-)

这篇关于nginx和Perl:FastCGI与反向代理(PSGI/Starman)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！