aaa*_*210 19 perl reverse-proxy fastcgi nginx plack
如今,运行Perl Web应用程序的一个非常流行的选择似乎是nginx webserver代理对FastCGI守护程序或PSGI启用的Web服务器(例如Starman)的请求.
关于为什么一般会这样做会有很多问题(例如为什么在Catalyst/Plack/Starman中使用nginx？)并且答案似乎适用于这两种情况(例如,允许nginx提供静态内容,轻松重启应用程序服务器,负载均衡等)
但是,我对使用FastCGI与反向代理方法的优缺点特别感兴趣.似乎Starman被广泛认为是最快和最好的Perl PSGI应用程序/网络服务器,我很难看到使用FastCGI的任何优势.这两种方法似乎都支持:
同样,任一选项的nginx配置都非常相似.
那你为什么选择一个呢？
jpe*_*zzo 15
反向代理设置(例如,向Starman转发HTTP请求的nginx)具有以下优点:
因为您可以轻松直接命中后端服务器,所以事情更容易调试;
如果你需要扩展你的后端服务器,你可以在前端(静态服务)HTTP和你的后端之间轻松使用像pound/haproxy这样的东西(Zope经常像那样部署);
如果你也使用某种面向外的缓存,反向代理(如Varnish或Squid),它可以是一个不错的搭档,因为它可以很容易地绕过它.
但是,它有以下缺点:
后端服务器必须找出真正的原始IP,因为它将看到的只是前端服务器地址(通常是localhost); 几乎有一种简单的方法可以找到HTTP标头中的客户端IP地址,但这是一个额外的问题;
后端服务器通常不知道orignal"Host:"HTTP头,因此,不能自动生成本地资源的绝对URL; Zope使用特殊URL解决这个问题,将请求中的原始协议,主机和端口嵌入到后端,但这与FastCGI/Plack/...没有关系.
前端不能自动生成后端进程,就像它可以用FastCGI做的那样.
选择你最喜欢的优点/缺点并做出你的选择,我猜;-)
| 归档时间： |
|
| 查看次数： |
8337 次 |
| 最近记录： |