清漆-> Nginx-> Apache好主意?


10

我正在考虑新的Web服务器的体系结构。将Varnish作为Nginx前面的缓存作为反向代理,并在apache前面为所有繁重的工作提供静态文件是一个好主意吗?

我将在Rails应用程序上运行php和ruby。

将php请求通过其他两个过程传递给apache会产生太多开销吗?

非常感谢!

Answers:


8

是的,这是有效的。我的个人方法是预先使用Varnish并使用VCL在静态NGINX请求和繁重的工作(无论是Apache还是Passenger还是...无关紧要)之间分配流量。这是尤其如此,如果它在同一台机器上,你不需要额外的开销。它不一定能买任何东西。


是的,这是一个很好的主意,因为清漆应该很快就可以了
Zoran Zaric 2010年

6

Varnish目前尚不支持gzip压缩,因此最好将其与nginx交换以压缩varnish发送回的内容。由于varnish和nginx不会争用相同的资源(nginx使用CPU进行gzip压缩,而varnish使用内存),它们应该在同一台机器上流畅运行。

Varnish现在支持gzip压缩,因此,除非需要SSL终止(如注释中所建议),否则我建议将varnish直接与Internet联系。

对于http:

(互联网)->(清漆,gzip,缓存,esi)->(应用程序)

对于https:

(互联网)->(nginx,ssl)->(清漆,gzip,缓存,esi)->(应用程序)

如果您也想在其中添加Apache(以获得对mod_foobar的普遍支持),我会将其放在清漆和应用程序之间

更新:更新以在清漆3.0中包括gzip支持。按照评论中的建议添加了ssl / esi


如果提供内容的任何内容均以 gzip进行编码,则varnish会将其传递给gzip,而不会抱怨:varnish-cache.org/wiki/FAQ/Compression 唯一不做的事情是从未缓存的内容中提取未压缩的内容应用程序并保留它压缩。这也是您的理解吗?
ewalk 2010年

只有在使用ESI时,才在清漆前运行nginx。由于您不能从压缩的页面进行ESI组装,并且Varnish不会压缩组装的页面,因此Nginx放在Varnish的前面以提供该压缩。如果源提供压缩的内容,则Varnish会将数据以压缩形式传递给客户端。
user6738237482 2010年

是的,ESI是我推荐此配置的原因之一,但是我想如果后端压缩并且不使用ESI,则可以省去nginx,因为我相信清漆可以处理很多流量而无需流汗。
mogsie

@ user6738237482,nginx支持SSL终止,Varnish不支持。实际上,面对像varnish或Apache之类的东西,正是nginx最初设计的目的,它是一种快速,轻便的代理服务器。
rmalayter 2011年

4

开销的数量应该不大。我假设要拥有这两个层次的部分原因是为了可伸缩性。在这种情况下,相对于apache,您最有可能会看到清漆和nginx并不是很辛苦。

如果将所有三层都放在一台计算机上,则在达到服务器本身的容量之前,对性能的影响应该较小。

作为替代方案,为什么不对乘客涂清漆+ Nginx?我过去使用过这种设置,而使用passenger的nginx相对较轻,并且运行得很好。如果您不结婚使用Apache运行Rails Stack,可能值得考虑。


是的,我可能将Apache从Rails切换到Nginx,但是让客户能够使用.htaccess文件是Apache的+,至少适用于php。
Zoran Zaric 2010年

2

我是启动电子商务平台的系统管理员。我们在PHP / apache堆栈之前使用varnish + nginx,它产生了奇迹。

我们有一个内存使用率很高的应用程序,该应用程序每个Web节点使用大约15-20gig的RAM,一旦将清漆放在前面,现在每个节点大约8gig的RAM。他们从来没有加价。

因此,我强烈推荐它。


3
您知道清漆不讲SSL吗?
Mike

1

我正在运行Drupal,在Apache + PHP + MySQL服务器上使用boost模块,但在它们前面,我使用的是启用了gzip-static功能的Nginx,并使用boost的结果为用户提供服务。

最重要的是,我在同一台PC上都使用清漆,效果很好。

我还使用Nginx来调整Drupal对于缓存不是很好的标头。


0

除非您需要类似ESI的东西,否则这不是一个好主意。Nginx拥有自己的性能更好的缓存系统。


我知道这是一个旧答案,但是很遗憾,该链接不再可用,因此我无法验证您的主张。以我的经验,Varnish作为反向代理在速度和灵活性方面是无与伦比的。
Martijn Heemels,2015年


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.