Web 缓存的陷阱 400 请求报错 

我们尝试过很多工具来提高性能，例如 Profilers，各种 web 服务器，APC，xcache，memcache，redis等等。但是没有哪个技术能像 Varnish 那样带来如此大的性能提高。我们使用 Varnish 来解决大大小小的问题。在绝大多数情况下，它能很好的工作，为我们节约了大量的金钱。但这不意味着它就没有问题。这篇文章写的就是使用 Varnish 这类技术的一些注意点。

性能问题

当你启用缓存的时候，请记住你并没有“解决”任何问题。页面装载变快是因为你跳过了复杂的页面渲染过程，但是假如你的缓存没有该页面，那么整个装载还是会一样缓慢。当你将有 session 的请求传到后端服务器的时候，响应就会变的很慢。所以，使用缓存来减少装载时间，但也必须解决底层的性能问题。

重写

我们使用了很多 URL 重写的技术。重写可以规范 URL 形式，没有人想要看到 wiki/index.php?title=Foo 这样的地址。不幸的是，URL 重写会让逻辑变的复杂，它会将请求的 URL 作为累加器。重写也让测试变的困难，因为它要建立在缓存服务器之上。

如果可以选择的话，请不要将重写构建于缓存服务器上，它非常难以调试，并且非常脆弱。尽可能的使用重定向，虽然会慢一点点。

复杂的逻辑

重写并不是唯一把事情变复杂的技术。通过 Varnish 你很容易创建复杂的逻辑。你可以对每一个请求设置不同的条件。当你这么做的时候，你需要问问你自己是不是真的有必要。你也许会发现在缓存中实现一些逻辑虽然更快速，但还是在应用中实现更为妥帖。请记住，缓存是很难调试的。你并不清楚你的逻辑在一个缓存周期中是否成立。

总结

我的建议是 Web 缓存很容易，但是请尽量保持简单。请尽量不要在缓存中存放业务逻辑。还有，请不要忽略程序的性能问题，缓存不能解决全部的问题。   原文链接，OSChina.NET 编译