接下来是varnish的性能调整参数及运行时参数调整以后,varnish的性能和支持的最大并发量,比如varnish的众多客户端命令行工具,该如何使用
对于varnish的配置文件,主要有两类参数配置,
一类是配置缓存策略,VCL
一类是配置varnish进程自己的工作特性的
opt策略的时候运行时可更改参数
这些参数每个参数都有特定的意义
神秘工具varnish tuner,安装以后也能完成所谓的调整
找不到可以在命令行下使用param set调整(临时的,想要永久有效,只能编辑特定的文件)
经常调整的有threading model
ban
accepter接收用户请求
epoll/kqueue这个是基于单进程响应多个用户进行
expire 把过期缓存清除
backend poll 对后端服务器做健康监测
thread_pools 线程池数量
如果想要实现4个线程池,一个线程池相当于对应 nginx中的worker,一个worker可以有多个线程
一个线程池数量应该小于CPU物理核心数
每一个线程池当中还可以实现定义(thread_pool_min/max)每个池最少(代表初始化数量),最大线程数(等于一个进程允许的最大并发连接数,默认是5000个)
epel安装的默认数量未必是这么多
空闲线程的超时时长,最少100个,相当于最多只能空闲100个,超出的线程,5分钟以后会被删除,只保留100个
指线程池的等待队列长度,每个线程池后援队列的长度是多少
杀死线程要犹豫1秒钟,万一1秒钟之内有大量请求来呢,那我们就省得来创建了,(让timeout的时间多分1秒钟)
在创建时就不要延迟了(在实现序列化创建线程时,延迟0秒创建下一个,立即创建所需要的线程)
创建一个线程失败时,要等上0.2秒,再去重试
这个300秒可能 太短了,改成3000秒比较合适
偶尔也要调整计时器下的参数
connect——timeout 链接超时时间,设置时间过短,客户端可能会出现502,找不到后端服务器
send_timeout 发送响应报文给客户端的超时时长,
保持链接的超时时长的
保持链接默认varnish是启动的,(这里的客户端可能指的是nginx或者其他调度器)这里可以适当调长,这样每个链接就可以多多复用了
等待客户端发送请求报文的首部,的超时时间,如果认为2秒果断,可以长一点
是用varnish链接发出指令请求时,requests的响应超时时长
一般调整这个,可以调整前端反向代理服务器的超时时间
反向代理服务器作为客户端,也是需要打开端口,如果开启长连接,可以省去三次握手,还可以少开端口
想要永久生效写在这里
现在改成2000,这样服务器最大连接数就是8000,2000*4
服务器的最大连接数可能取决于你的短板
现在重启一下varnish
现在说一下日志区域,日志区域是在内存中的,大概有80M
前一部分是计数器(比如服务器总共命中了多少次)
下面的是看日志
实时查看的,不是查看之前,是看后来请求发生的
查看ncsa格式
类似于nginx日志格式commind
简单地对这些内容进行压测
top是用来排序的
对你的时间做一个排序,而且时间一直是倒计时,按时间流逝做的平均值
所以按照次数最多的,自上而下的排列,对日志中的日志项出现次数速率平均以后自上而下或逆向排序的
对日志区域来讲 有几种 用法
-1 只显示1次
基于批次显示,把所有的对应项只显示一次
主要关注main段,main中有些值比较关注
命中数除以请求数,基本上是一个命中率
将来也可以写一个脚本把这两个值获取出来,不断去显示每秒的命中多少次,监控系统,互联网上的模版很多,拿过来可以直接用
**如果只想看到某个指定的filed **
每一项都可以单独查看
也可以指定main段 的所有值
显示两个段
varnishtop可以对varnishi日志做排序
-1做一次显示
一个请求对应一个deliver
前面是统计数计
**首部虽然相同但是值不同也户列出的,想要筛选自己感兴趣的 **
跟上正则表达式做匹配
没有请求
这个是发往后端服务器的请求
命中了就不显示
查看响应码
做请求才会显示
可以过滤更复杂的标签
但是这个值并不一定符合我们需要
可以过滤掉
根据正则表达式过滤出来自己想要看到的
过滤掉不想看到的
运行一个守护进程,把取得的结果直接保留在指定文件中
追加的方式保存到指定的文件中
-D守护进程,-p指明PID文件
用法是一样的
varnishncsa是基于commind来记录日志的
可以指定输出格式
**这个格式跟http的格式一模一样如果需要varnish去记录日志(因为varnish不会直接面向客户端,一般都是nginx)
**
如果不得不在缓存服务器上记
接着做一次请求
一旦启用日志,必然会对IO很大压力,部署varnish主机的时候,尽量把你的缓存放在一个磁盘上