每一个来自客户端请求在varnish中都是一个session,一个session会被分配到一个空闲的thread处理。 当没有空闲的thread时,varnish会创建新的thread来处理。 当全局的thread数量超过thread_pool_max * thread_pools时, varnish会将请求放入队列,当队列满时,varnish开始丢弃请求。 Varnish的默认配置,thread_pools2thread_pool_max500,也即最多1000thread。 当并发处理的请求量(注意不等价与并发请求量)大于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


调整完成查看一下

wKioL1PyqsLwkyerAAGo6zbObzI431.jpg

注意:thread_pools 参考机器物理核心的数量,官方建议设置为2。线程数不建议太多,超过5000也许会带来服务不稳定。


配置调优

beresp.grace 表示一个object即使已经过期了,仍然在缓存中存放一段时间。

req.grace 表示,当一个请求命中了一个刚过期的object,由于回源需要一段时间, 为了立刻返回,那么在过期后的req.grace时间内, 可以将过期的那个object返回给客户端, 当然,这要求beresp.grace >= req.grace

Example:

wKioL1PyrvzCQNGnAAGJOrPmJJU463.jpg

与Cookie有关的缓存

业务要求大致如此,对于一个domain下的请求,客户端总是会带Cookie, 而该domain下面有一些请求是需要缓存的。在之前的配置中,vcl_recv中设置了只要有Cookiereturn(pass), 因此如果某个url需要缓存,就需要手动对该urlvcl_recv中 删除req.http.Cookie,并在vcl_fetch中删除beresp.http.Set-Cookie。 这样运维的工作与后端的开发工作就耦合了。期望的效果是,后端如果需要缓存某个url,则在该请求的返回头中带有Cache-Control头, 然后Varnish就自动根据该头来缓存相应的时间,而如果一个请求的返回中没有Cache-Control头,则默认不能缓存。

wKiom1Pys7qTT84_AAFT8QaB0JU537.jpg



varnishstat  用于查看varnish状态

wKioL1PyrZTCB5u_AAZtXpS0wzU747.jpg






日志功能的使用

  • Service varnishlog start 

查看日志

  • varnishlog

本章内容并非全部原创,有引用大牛网友的分享。


推荐阅读:http://blog.csdn.net/keda8997110/article/details/8777153