本文来自网易云社区
作者:孙建良
Webpolygraph 可以阶段性的控制 workload,阶段性控制负载的变化,可以指定不同阶段的访问强度 ,访问命中率等等。
Phase{
string name //阶段名字
Goal goal //完成该阶段的指标
Goal{
time duration; //持续时间
int xactions; //完成的请求次数
size fill_size; //实际往缓存里面灌了多少数据
float errors; //出现错误的概率或者次数为指标
}
float load_factor_beg //load 的起始与终止强度(即 TPS) 0.0 1.0
float load_factor_end
float recur_factor_beg //控制起始于终止 URL 重复率
float recur_factor_end
float populus_factor_beg//用于定义此阶段的 robot 的起始于终止存活百分比
float populus_factor_end
Rptmstat rptmstat
float special_msg_factor_beg
float special_msg_factor_end
statsSample [ ]stats_samples
bool log_stats //用于控制是否记录 log,用于生产报告
bool wait_wss_freeze
bool primary
}
Size CacheSize = 100G
Phase phFill = {
name = "fill"; //阶段名称
recur_factor_beg = 0.05; //起始与终止 URL 重复比例
recur_factor_end = 0.05;
load_factor_beg = 1.0;
load_factor_end = 1.0;
goal.fill_size = CacheSize; //该阶段完成指标为向 proxy 灌 100G 数据};
Phase phTop1 = {
name = "top";
recur_factor_beg = 0.95;
recur_factor_end = 0.95;
load_factor_beg = 1.0; //发送请求的速度(100%的目标 TPS)
load_factor_end = 1.0;
goal.duration = 30min; //该阶段指标为跑 30 分钟
};
Phase phCool = {
name = "cool";
goal.duration = 1min;
load_factor_beg = 0; //不发送请求
load_factor_end = 0;
log_stats = false; //不记录该段的 log 数据
};
Phase phTop2 = {
name = "middle";
recur_factor_beg = 0.5;
recur_factor_end = 0.5;
load_factor_beg = 0.5; //发送请求的速度(50%的目标 TPS)
load_factor_end = 0.5;
goal.duration = 10min;
};
测试阶段图:fill -> cool -> top -> cool -> middle -> cool
� Poly server 使用:./polygraph-server --config XXX.pg --verb_lvl 10 --log XXX.log--config 指定使用的配置文件,--log 指定生产的 log 名,--verb_lvl 指定 log 的繁简程度。
� Poly client 使用:./polygraph-client --config XXX.pg --proxy 172.17.0.48:8066 --verb_lvl 10 --logXXX.log--proxy 指定 proxy 的地址与监听端口。
� Poly report 使用:./polygraph-reporter --label "steady" --phases top --phases normal --phases peacesteady_client.log steady_server.log--label 指定生产报告数据所在文件夹名字,--phases 指定 workload 中使用的 phases,若有多个指定多个,不配置默认使用第一阶段,所有加上生产的 log 文件名用以生产报告(可以仅使用 client 端 log 或者 server 端 log 或者两者都使用)。
� 报告能够得到的数据
1:load trace 负载报告
2:response time 报告(average / min/max)
3: response time 负载分布图
4: 请求的数据大小分布图
5:document hit rate
6: byte bite rate
7:更多参考:http://172.17.4.112:9000/ats-ssd-4/
下图为简单的配置环境,Inspur112 上跑 poly client,inspur114 上跑 poly server,inspur115上跑 ATS。Inspur112 的 ip 为 172.17.4.112, inspur114 的 ip 为 172.17.4.114,inspur115 的 ip为 172.17.4.115。
----------------------------simpleworkload.pg--------------------------
size CacheSize = 1GB;
Content SimpleContent = {
size = exp(35KB);
cachable = 100%;
};
Server S = {
kind = "S101";
contents = [SimpleContent];
direct_access = contents;
addresses = ['172.17.4.114:9099'];};
Robot R = {
kind = "R101";
pop_model = {
pop_distr = popZif(0.6);
};
req_rate = 4/sec;
recurrence = 100%/SimpleContent.cachable;
origins = S.addresses;
addresses = ['172.17.4.112'**100];
};
Phase phFill = {
name = "fill";
recur_factor_beg = 0.05;
recur_factor_end = 0.05;
goal.fill_size = CacheSize;
};
Phase phTop1 = {
name = "top";
recur_factor_beg = 0.95;
recur_factor_end = 0.95;
goal.duration = 5min;
};
Phase phCool = {
name = "cool";
goal.duration = 1min;
load_factor_beg = 0;
load_factor_end = 0;
log_stats = false;
};
Phase phTop2 = {
name = "middle";
recur_factor_beg = 0.5;
recur_factor_end = 0.5;
goal.duration = 5min;
};
schedule(phFill, phCool, phTop1, phCool, phTop2, phCool);
use(S, R);
-----------------------------------------------------
客户端线程数:100
平均文件大小:35k(大小分布为指数分布)
基准 TPS 为:100 client * 4/sec = 400/sec
keepalive:开启
测试阶段分为:fill -> cool -> top -> cool -> middle -> cool(如下图所示)fill 阶段的目标是向缓存服务器填充 1G 数据,缓存命中为 5%
cool 阶段停止测试
top 阶段缓存命中率为 95%,用以模拟线上环境
middle 阶段缓存命中率为 50%,用以与 top 阶段对比
� Inspur115 上配置并启动 trafficserver
-----------------------------------------配置 record.conf-------------------------------------------------
CONFIG proxy.config.http.server_port INT 8066
CONFIG proxy.config.reverse_proxy.enabled INT 1
CONFIG proxy.config.header.parse.no_host_url_redirect STRING http://
172.17.4.114:9099
-----------------------------------------配置 remap.conf-------------------------------------------------
map http:// 172.17.4.115:9000/ http:// 172.17.4.15:9000/
---------------------------------------------------------------------------------------------------------------- 启动 trafficserver: ./trafficserver start
� Inspur114 上执行 polyserver
./polygraph-server --config simpleworkload.pg --verb_lvl 10--log ./simpleworkload_server.log
� Inspur112 上执行 polyclient
./polygraph-client --config simpleworkload.pg --proxy 172.17.4.115:8066--verb_lvl 10 --log simpleworkload _client.log
� 生成报告
将 log 都内容拷贝到 112 上,并生成报告
./polygraph-reporter --label "polytest" --phases fill --phases top --phases middle
--phases cool simpleworkload _client.log simpleworkload_server.log
� 查看报告
到 达 /tmp/polyrep/polytest 目 录 下 执 行 简 单 的 python http 服 务 器 , python -mSimpleHTTPServer 9000
输入 web broser 中输入地址 http:// 172.17.4.112:9000:/ 即可看到类似以下测试结果页面
� WebPolyGraph 没有包含 proxy 服务器负载信息(cpu/IO/Net/Mem)
描述:WebPolyGraph 没有统计代理服务器负载功能
解决方法:可以通过记录起止测试时间通过运维平台获取对应的信息。
� 关于 best effort 模式下的 load 强度的不可控性
描述:设置 best effort 模式,在 phase 中不能对负载强度进行控制,load_factor_beg ,load_factor_beg 设置但是从结果看没有奏效。
解决方法:要配置 Robot 的 req_rate 才能是的 load_factor 奏效。
� 关于瓶颈
描述:在测试 ssd 的时候要注意网络,网络基本会成为瓶颈,同样测试比如 ram 的时候实际能够给出的 TPS 是非常高的。但是由于网络的原因,不能体现出测试结果。
解决方法:三方(polyclient,polyserver,proxy)都放在一块。
� 测试方式
描述:如果响应延迟与机房到 xshell 这块的响应时间在一个数量级的,测试最终结果会有比较大的偏差。
解决方法:最好放在 screen 或者后台运行。
� 关于 pop_modle 与对应的命中率,以及对 ram 的测试的影响
描述:实际测试过程中发现实际测试结果的命中率不能够达到自己预设的命中率
原因:proxy 设置缓存过小,导致灌数据的大小远远超过缓存大小,导致之前 URL 对应的数据被换出,第二次访问同样 URL 其实之前的已经被换出。
解决:方法 1:设置 proxy 缓存很大,并首先灌很多,然后再进行测试
方法 2:使用 popzipf 而不是 popunif 方式的 URL 重复控制。
� 关于长连接的设置的性能
描述:测试 Nginx HDD 的时候总是出现 client 不能正常连接 proxy,connect 出错的问题。
原因:最后发现是由于没有设置好长连接的问题,(很多tcp连接的状态是TIME_WAIT)。
解决方法:(robot 和 sever 都进行如下设置)pconn_use_lmt=const(2147483647)
1. Web Polygraph 官方主页
2. Performance Evaluation of the Apache Traffic Server and Varnish
Reverse Proxies
3. High Performance Benchmarking with Web Polygraph
4 : 内 部 使 用 Web Polggraph 对 traffic server 进 行 测 试 的 文 档 :http://172.17.2.201:8000/html/
网易云免费体验馆,0成本体验20+款云产品!
更多网易研发、产品、运营经验分享请访问网易云社区。