参考：
https://www.varnish-cache.org/docs/4.1/users-guide/increasing-your-hitrate.html
-
Achieving a high hitrate
翻译内容:
到现在为止，你的varnish已经运行起来了，你能访问你的web应用了通过varnish。除非你的web应用程序开始写的时候就工作在一个web加速器的后面，否则你将需要去改变你的配置文件或者应用为了提高缓存命中率。
varnish将不缓存你的数据，除非绝对的确信它这样做是安全的。因此你需要懂得varnish是否决定和怎样去缓存一个页面的。我们将引导你使用三两个工具，这两个工具是非常有用的对于去理解懂得varnsh的设置将会发生什么效果。
注:你需要一个工具去看http的头部信息在varnish和后端服务器之间传输之间，有一个很容易的方法是去使用varnishlog and varnishtop(这两个命令)，但是有时候一个client-side工具会更加清晰(如curl命令)。这是我们通常使用的
-
工具: varnishtop
你可以使用varishtop查看那个urls是被请求到了后端服务器。使用 varnishtop -i BereqURL 是一个最好最本质的命令。显示最高的请求被发送到了后端。你能看到一些其他的例子使用varnishtop
本人喜欢用:
varnishtop -i ReqURL #查看那个url访问最多
varnishtop -i BereqURL # 透过varnish到后端的请求那个多，一般是排除MISS高的原因
-
Tool: varnishlog
当你确定发下一个url频繁的发送到后端服务器时候，你能使用varnishlog去查看这个请求，
varnishlog -q ‘ReqURL ~ "^/foo/bar"‘ 它将显示来自客户端匹配/foo/bar的请求。
获取更多的信息关于varnishlog的工作，请查看 Loggin in Varnish章节，或者man帮助文档。
https://www.varnish-cache.org/docs/4.1/users-guide/operation-logging.html
-
Tool: lwp-request
lwp-request is tool that is a part of The World-Wide Web library for Perl.
是一个perl语言的开源工具，centos上安装使用 yum install perl-libwww-perl 可以获取。
我们常用 GET 和 HEAD命令，它可以详细的显示出请求的http head和响应的 http response
$ GET -H ‘Host: www.vg.no‘ -Used http://vg.no/ GET http://vg.no/ Host: www.vg.no User-Agent: lwp-request/5.834 libwww-perl/5.834 200 OK Cache-Control: must-revalidate Refresh: 600 Title: VG Nett - Forsiden - VG Nett X-Age: 463 X-Cache: HIT X-Rick-Would-Never: Let you down X-VG-Jobb: http://www.finn.no/finn/job/fulltime/result?keyword=vg+multimedia Merk:HeaderNinja X-VG-Korken: http://www.youtube.com/watch?v=Fcj8CnD5188 X-VG-WebCache: joanie X-VG-WebServer: leon
-H 添加请求头部
-U print request headers,
-s prints response status,
-e prints response headers and
-d discards the actual content
-
Tool: Live HTTP Headers
一个火狐浏览器的插件，这插件能显示请求和接收的头部信息。
-
The role of HTTP Headers
随着每一个http的请求和响应，都携带这头部信息元数据。varnish检查这些头部信息决定如何使用适当的方式去缓存这些内容并决定缓存的时长。
请注意varnish考虑这些头部，varnish实际是考虑他自己做为web服务器的一部分。这理论基础是在你的控制之下。(以下这句不好翻译)
Please note that when Varnish considers these headers Varnish actually considers itself part of the actual webserver. The rationale being that both are under your control.
这项代理缓存来源不是被很好的定义在iETF和RFC 2616中，所以varnish各样的工作方式可能和你期待的不一样。
让我们看看这些重要的头部，你是需要知道的。
-
Cookies