每一个来自客户端请求在varnish中都是一个session，一个session会被分配到一个空闲的thread处理。 当没有空闲的thread时，varnish会创建新的thread来处理。 当全局的thread数量超过thread_pool_max * thread_pools时， varnish会将请求放入队列，当队列满时，varnish开始丢弃请求。 Varnish的默认配置，thread_pools为2，thread_pool_max为500，也即最多1000个thread。 当并发处理的请求量（注意不等价与并发请求量）大于1000时，varnish就过载了。
下面我们来看看如何调整线程池
管理命令：
Varnishadm
param.show -l //列出所有配置参数，与注释。
Param.show
thread_pool_max 1000 [threads] //定义线程池最大线程
thread_pool_min 50 [threads] //每个线程池最小活动线程
thread_pools 2 [pools] //启用多少个线程池
lru_interval 2 [seconds] //使用（LRU）最近最少使用算法，清理缓存对象的频率，默认2秒一次。
listen_depth 1024 [connections] //当线程池满了，后续请求队列的长度。
现在我们对这些参数进行调整
param.set thread_pool_max 2000
param.set thread_pools 4
param.set thread_pool_min 100
调整完成查看一下
注意：thread_pools 参考机器物理核心的数量，官方建议设置为2。线程数不建议太多，超过5000也许会带来服务不稳定。
配置调优
beresp.grace 表示一个object即使已经过期了，仍然在缓存中存放一段时间。
req.grace 表示，当一个请求命中了一个刚过期的object，由于回源需要一段时间， 为了立刻返回，那么在过期后的req.grace时间内， 可以将过期的那个object返回给客户端， 当然，这要求beresp.grace >= req.grace
Example：
与Cookie有关的缓存
业务要求大致如此，对于一个domain下的请求，客户端总是会带Cookie， 而该domain下面有一些请求是需要缓存的。在之前的配置中，vcl_recv中设置了只要有Cookie就return(pass)， 因此如果某个url需要缓存，就需要手动对该url在vcl_recv中 删除req.http.Cookie，并在vcl_fetch中删除beresp.http.Set-Cookie。 这样运维的工作与后端的开发工作就耦合了。期望的效果是，后端如果需要缓存某个url，则在该请求的返回头中带有Cache-Control头， 然后Varnish就自动根据该头来缓存相应的时间，而如果一个请求的返回中没有Cache-Control头，则默认不能缓存。
varnishstat 用于查看varnish状态
日志功能的使用
Service varnishlog start
查看日志
varnishlog
本章内容并非全部原创，有引用大牛网友的分享。
推荐阅读：http://blog.csdn.net/keda8997110/article/details/8777153
