Tux,Varnish或Squid？

我们需要一个用于静态图像的Web内容加速器,它们位于我们的Apache Web前端服务器之前

我们以前的托管合作伙伴使用Tux取得了巨大的成功,我喜欢它是我们正在使用的Red Hat Linux的一部分,但它的最后一次更新是在2006年,并且似乎未来发展的可能性很小.我们的ISP建议我们在反向缓存代理角色中使用Squid.

Tux和Squid之间的想法？兼容性,可靠性和未来支持对我们而言与性能同等重要.

另外,我在这里阅读其他关于清漆的帖子; 任何人都有与Vquid相比,Varnish的实际经验,和/或Tux,在高流量环境中获得？

干杯

伊恩

更新:我们现在正在测试Squid.使用ab以100的并发率将相同的图像拉出10,000次,Apache本身和Squid/Apache都非常快速地通过请求烧毁.但是Squid只向Apache提出了一个请求,然后从RAM中提供了所有这些请求,而Apache只需要派遣大量工作人员来为图像提供服务.看起来Squid可以很好地释放Apache工作人员来处理动态页面.

根据我的经验,清漆比鱿鱼快得多,但同样重要的是它比鱿鱼的黑盒子要少得多.Varnish使您可以访问非常详细的日志,这些日志在调试问题时非常有用.它的配置语言也比鱿鱼更简单,更强大.

@Daniel,@ MKUltra,详细说明Varnish所谓的cookies问题,实际上并没有.这是完全正常的不是它是否会返回一个cookie与它缓存的请求.Cookie主要用于区分不同的用户偏好,因此我不认为会想要缓存这些(特别是如果你包含一些秘密信息,如会话ID或密码!).

如果您的服务器发送带有.js和图像的cookie,那么您的后端方面就会出现问题,而不是Varnish方面的问题.正如@Daniel所提到的(链接提供),你可以强制缓存这些文件,这要归功于Varnish中集成的非常酷的语言/ DSL ......

如果您想要推送静态图像及其中的大量图像,您可能需要先查看一些基础知识.

您的应用程序应确保传递所有正确的标头,例如Cache-Control和Expires.这应该导致客户端浏览器在本地缓存这些图像并减少您的请求数量.

使用CDN(如果它在您的预算中),这会使图像更接近您的客户(通常),并为他们带来更好的用户体验.要使CDN成为高效投资,您需要确保所有必要的缓存标头都已正确设置,这与我在上一段中所做的一致.

毕竟,如果您仍然要使用反向代理,我建议在代理模式下使用nginx,而不是Varnish和squid.是的,Varnish速度快,速度和nginx一样快,但是你想要做的事情非常简单,当你想要进行复杂的缓存时,Varnish会自己进入,而ESI也是如此.所以保持简单,愚蠢.nginx确实可以很好地完成你的工作.

我对Tux没有经验,所以我不能对此发表评论.

值得一提的是,我最近在一个6年前的低功耗网络服务器(运行Fedora Core 2)上设置了nginx作为Apache前面的反向代理,该服务器受到轻度DDoS攻击(10K req/sec).页面加载速度很快(<100毫秒),系统负载保持低水平,CPU利用率约为20%,内存消耗很少.袭击持续了一周,游客没有看到任何不良影响.

每分钟超过50万次点击持续不错.请务必记录到/ dev/null.