apache 燕尾服、清漆或鱿鱼？

Tux, Varnish or Squid?

提问by Polsonby

We need a web content accelerator for static images to sit in front of our Apache web front end servers

我们需要一个用于静态图像的 Web 内容加速器来放置在我们的 Apache Web 前端服务器之前

Our previous hosting partner used Tux with great success and I like the fact it's part of Red Hat Linux which we're using, but its last update was in 2006 and there seems little chance of future development. Our ISP recommends we use Squid in reverse caching proxy role.

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

Any thoughts between Tux and Squid? Compatibility, reliability and future support are as important to us as performance.

Tux和Squid之间有什么想法吗？兼容性、可靠性和未来支持对我们来说与性能一样重要。

Also, I read in other threads here about Varnish; anyone have any real-world experience of Varnish compared with Squid, and/or Tux, gained in high-traffic environments?

另外，我在这里阅读了有关清漆的其他主题；与在高流量环境中获得的 Squid 和/或 Tux 相比，有人对 Varnish 有任何实际经验吗？

Cheers

干杯

Ian

伊恩

UPDATE: We're testing Squid now. Using ab to pull the same image 10,000 times with a concurrency of 100, both Apache on its own and Squid/Apache burned through the requests very quickly. But Squid made only a single request to Apache for the image then served them all from RAM, whereas Apache alone had to fork a large number of workers in order to serve the images. It looks like Squid will work well in freeing up the Apache workers to handle dynamic pages.

更新：我们现在正在测试 Squid。使用 ab 以 100 的并发性拉取同一个镜像 10,000 次，Apache 本身和 Squid/Apache 都非常快速地完成了请求。但是 Squid 只向 Apache 发出一个图像请求，然后从 RAM 中为所有这些图像提供服务，而 Apache 单独必须分叉大量的工作人员才能为图像提供服务。看起来 Squid 可以很好地释放 Apache 工作人员来处理动态页面。

回答by scottynomad

In my experience varnish is much faster than squid, but equally importantly it's much less of a black box than squid is. Varnish gives you access to very detailed logs that are useful when debugging problems. It's configuration language is also much simpler and much more powerful that squid's.

根据我的经验，清漆比鱿鱼快得多，但同样重要的是，它比鱿鱼更像是一个黑匣子。Varnish 使您可以访问非常详细的日志，这些日志在调试问题时非常有用。它的配置语言也比鱿鱼的简单得多，而且功能强大得多。

回答by Luc Stepniewski

@Daniel, @MKUltra, to elaborate on Varnish's supposed problems with cookies, there aren't really any. It is completely normal notto cache a request if it returns a cookie with it. Cookies are mostly meant to be used to distinguish different user preferences, so I don't think one would want to cache these (especially if you they include some secret information like a session id or a password!).

@Daniel，@MKUltra，要详细说明 Varnish 的 cookie 问题，实际上并没有。如果请求返回一个 cookie，则不缓存请求是完全正常的。Cookies 主要用于区分不同的用户偏好，所以我认为人们不会想要缓存这些（特别是如果它们包含一些秘密信息，如会话 ID 或密码！）。

If you server sends cookies with your .js and images, that's a problem on your backend side, not on Varnish's side. As referenced by @Daniel (link provided), you can force the caching of these files anyway, thanks to the really cool language/DSL integrated in Varnish...

如果您的服务器发送带有 .js 和图像的 cookie，那是后端的问题，而不是 Varnish 的问题。正如@Daniel（提供链接）所引用的那样，您无论如何都可以强制缓存这些文件，这要归功于 Varnish 中集成的非常酷的语言/DSL...

回答by flungabunga

If you're looking to push static images and a lot of them, you may want to look at some basics first.

如果您希望推送静态图像和大量静态图像，您可能需要先了解一些基础知识。

Your application should ensure that all correct headers are being passed, Cache-Control and Expires for example. That should result in the clients browsers caching those images locally and cutting down on your request count.

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

Use a CDN (if it's in your budget), this brings the images closer to your clients (generally) and will result in a better user experience for them. For the CDN to be a productive investment you'll again need to make sure all your necessary caching headers are properly set, as per the point I made in the previous paragraph.

使用 CDN（如果它在您的预算范围内），这会使图像更接近您的客户（通常）并且将为他们带来更好的用户体验。为了让 CDN 成为一项富有成效的投资，您将再次需要确保正确设置所有必要的缓存标头，正如我在上一段中提出的观点。

After all that if you are still going to use a reverse proxy, I recommend using nginx in proxy mode, over Varnish and squid. Yes Varnish is fast, and as fast as nginx, but what you're wanting to do is really quite simple, Varnish comes into it's own when you want to do complex caching, and ESI. So Keep It Simple, Stupid. nginx will do your job very nicely indeed.

毕竟，如果您仍然要使用反向代理，我建议在代理模式下使用 nginx，而不是 Varnish 和 squid。是的，Varnish 很快，和 nginx 一样快，但是你想要做的真的很简单，当你想要做复杂的缓存和 ESI 时，Varnish 就派上用场了。所以保持简单，愚蠢。nginx 确实可以很好地完成您的工作。

I have no experience with Tux, so I can't comment on it sorry.

我没有使用 Tux 的经验，所以抱歉，我无法对此发表评论。

回答by tylerl

For what it's worth, I recently set up nginx as a reverse-proxy in front of Apache on a 6-year-old low-power webserver (running Fedora Core 2) which was under a mild DDoS attack (10K req/sec). Pages loading was snappy (<100ms) and system load stayed low at around 20% CPU utilization, and very little memory consumption. The attack lasted 1 week, and visitors saw no ill effects.

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

Not bad for over half a million hits per minute sustained. Just be sure to log to /dev/null.

每分钟持续超过 50 万次点击还不错。只要确保登录到 /dev/null。

回答by Abbas

It's interesting that no one mentioned the Apache Traffic Server (formerly, Yahoo! Traffic Server) http://trafficserver.apache.org/

有趣的是，没有人提到 Apache Traffic Server（以前称为 Yahoo! Traffic Server）http://trafficserver.apache.org/

Please have a look at it, it works beautifully.

请看看它，它运行得很漂亮。

回答by Richy B.

We use Varnish on http://www.mangahigh.comand have been able to scale from around 100 concurrent pre-varnish to over 560 concurrent post-varnish (server load remained at 0 at this point, so there's plenty of space to grow!). Documentation for varnish could be better, but it is quite flexible once you get used to it.

我们在http://www.mangahigh.com上使用 Varnish，并且已经能够从大约 100 个并发 pre-varnish 扩展到超过 560 个并发 post-varnish（此时服务器负载保持在 0，因此有足够的增长空间！）。清漆的文档可能会更好，但是一旦您习惯了它，它就会非常灵活。

Varnish is meant to be a lot faster than Squid (having never used Squid, I can't say for certain) - and http://users.linpro.no/ingvar/varnish/stats-2009-05-19shows Twitter, Wikia, Hulu, perezhilton.com and quite a number of other big names also using it.

Varnish 比 Squid 快很多（我从来没有用过 Squid，我不能肯定） - http://users.linpro.no/ingvar/varnish/stats-2009-05-19显示 Twitter， Wikia、Hulu、perezhilton.com 和许多其他大牌也在使用它。

回答by Javier

both Squid and nginx are specifically designed for this. nginx is particularly easy to configure for a server farm, and can also be a frontend to FastCGI.

Squid 和 nginx 都是专门为此设计的。nginx 特别容易为服务器群配置，也可以作为 FastCGI 的前端。

回答by Lasar

I've only used squid and can't compare. We use squid to cache an entire site on a server in the USA (all data gets pulled from a machine in Germany). It was pretty easy to set up and works nicely. I've found the documentation to be kind of lacking unless you already know what to look for.

我只用过鱿鱼，无法比较。我们使用 squid 在美国的服务器上缓存整个站点（所有数据都是从德国的一台机器上提取的）。它很容易设置并且运行良好。我发现文档有点缺乏，除非您已经知道要查找什么。

回答by Rafael Sanches

Since you already have apache serving the static and dynamic content I would recommend you to go with Varnish.

由于您已经拥有 apache 服务于静态和动态内容，我建议您使用 Varnish。

In this way you can use your apache to deliver the static content and use varnish to cache it for you. Varnish is very flexible, giving you both caching and loadbalancing features for growing your website in the best ways.

通过这种方式，您可以使用 apache 来交付静态内容并使用 varnish 为您缓存它。Varnish 非常灵活，为您提供缓存和负载平衡功能，以最佳方式发展您的网站。

回答by laughingbovine

Nobody mentions that Squid follows the HTTP specificationto the letter (or at least they try to) whereas Varnish does not. In my opinion, this means Varnish is better suited for caching content for individual sites (by extensively tuning Varnish) and Squid is better for caching content for many sites (each of which will have to make their content "cachable" according to spec).

没有人提到 Squid 完全遵循HTTP 规范（或者至少他们尝试这样做），而 Varnish 没有。在我看来，这意味着 Varnish 更适合缓存单个站点的内容（通过广泛调整 Varnish），而 Squid 更适合缓存许多站点的内容（每个站点都必须根据规范使其内容“可缓存” ）。