nginx和Perl: FastCGI vs反向代理(PSGI/Starman)
nginx和Perl: FastCGI vs反向代理(PSGI/Starman)
提问于 2010-10-23 19:20:50
现在运行Perl web应用程序的一个非常流行的选择似乎是在nginx web服务器后面代理对FastCGI守护进程或支持PSGI的web服务器(例如Starman)的请求。
关于为什么要这样做有很多问题(例如Why use nginx with Catalyst/Plack/Starman?)，答案似乎适用于这两种情况(例如允许nginx提供静态内容，轻松重启应用服务器，负载平衡等)。
然而，我特别感兴趣的是使用FastCGI和反向代理方法的优缺点。似乎Starman被广泛认为是最快、最好的Perl PSGI应用程序/web服务器，我很难看到使用FastCGI有什么好处。这两种方法似乎都支持：
TCP域套接字、sockets
- fork/process管理器风格的服务器以及非阻塞的基于事件(例如AnyEvent)的servers.
- Signal处理/优雅的restart
- PSGI
同样，任一选项的nginx配置都非常相似。
那么为什么你会选择一个而不是另一个呢？
回答 2
Stack Overflow用户
回答已采纳
发布于 2011-03-05 07:34:42
反向代理设置(例如，nginx将HTTP请求转发到Starman)具有以下优点：
- 的东西更容易调试，因为你可以很容易地直接访问后端服务器；
- 如果你需要扩展你的后端服务器，你可以很容易地在前端(静态服务)和你的后端之间使用庞德/haproxy这样的东西(Zope通常是这样部署的)；
- 如果你还使用了一些面向外部的、缓存的、反向代理(比如Varnish或Squid)，它可以是一个很好的伙伴，因为它允许非常容易地绕过它。
然而，它有以下缺点：
- 后端服务器必须找出真正的起始IP，因为它看到的只是前端服务器地址(通常是本地主机)；几乎有一种简单的方法可以在HTTP头中找出客户端IP地址，但这是一些额外的东西需要弄清楚；
- 后端服务器通常不知道原始的“主机：”HTTP头，因此不能自动生成到本地资源的绝对URL；
用特殊的URL来解决这个问题，将原始协议、主机和端口嵌入到后端的请求中，但这是你不需要用FastCGI/Plack/...;
- the前端做的事情，它不能像FastCGI那样自动产生后端进程。
选择你最喜欢的优点/缺点，然后做出你的选择;-)
Stack Overflow用户
发布于 2010-12-17 19:31:24
大多数系统管理员都能很好地理解HTTP，而且很容易调试。几乎总是已经部署了某种反向代理，所以只需在其配置中添加另一个配置节，以便在几秒钟内启动应用程序并运行，这是小菜一碟。我从来没有测试过这两种设置的速度差异，但另一方面，我在这方面从来没有遇到过任何问题，所以它不会那么糟糕。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/4003714
复制相关文章
相似问题
腾讯云开发者
