应用ab和wrk对腾讯云日志服务CLS进行压力测试，以此为例对ab和wrk进行阐明
ab
ab，全称是apache benchmark，是apache官网推出的工具。该工具是用来测试Apache服务器的性能的。查看装置的apache的服务器能提供的服务能力，每秒能够解决多少次申请。ab 执行时罕用的选项如下表：
| 选项 | 作用 |
|---|---|
| -c | 并发数， 一次发送的总申请数，默认是一次发一个申请。 |
| -k | 关上keep-alive，在一个HTTP Session中申请屡次。默认是敞开的。 |
| -n | 申请数， 整个benchmark测试过程中须要发送的申请次数。默认是一次，默认状况下失去的性能参数没有代表性。 |
| -t | 最大工夫，benchmark测试最长工夫，默认没有限度。 |
| -u | 上传文件，PUT操作时应用，须要设置-T选项 |
| -T | 设置上传文件的Content-Type |
| -p | postfile，指定蕴含post数据的文件 |
| -r | 当接管到socket谬误的时候ab不退出 |
<!--more-->
装置
apt-get install apache2-utils注意事项
- 察看测试工具ab所在机器，以及被测试的前端机的CPU，内存，网络等都不超过最高限度的75%。
- 测试中可能呈现端口有余导致的测试失败
须要调整内核参数以反对端口重用，在Linux平台下须要在/etc/sysctl.conf文件中增加如下内容
net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_fin_timeout = 30kernel.printk = 7 4 1 7而后运行sudo sysctl –p失效
应用示例
ab -c 50 -t 60 -n 300000 -k -T 'application/x-protobuf' -p /tmp/post_data.txt -H 'Host: ap-shanghai.cls.myqcloud.com' -H 'Authorization: q-sign-algorithm=sha1&q-ak=AKIDMfonbuXfqpcFicn3YrzwivMelfNwFWcW&q-sign-time=1517472219;1517493819&q-key-time=1517472219;1517493819&q-header-list=content-type;host&q-url-param-list=&q-signature=4a4ed6ddc8ba1dfea73d2bee62def9dce8b0ca3c' http://ap-shanghai.cls.myqcloud.com/log/tmp/post_data.txt数据为google protocol buffer格局的数据
后果剖析
This is ApacheBench, Version 2.3 <$Revision: 1796539 $>Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Software Foundation, https://www.apache.org/Benchmarking ap-shanghai.cls.myqcloud.com (be patient)Completed 30000 requestsCompleted 60000 requestsCompleted 90000 requestsCompleted 120000 requestsCompleted 150000 requestsCompleted 180000 requestsCompleted 210000 requestsFinished 223877 requestsServer Software: openrestyServer Hostname: ap-shanghai.cls.myqcloud.comServer Port: 80Document Path: /logDocument Length: 0 bytesConcurrency Level: 50Time taken for tests: 60.001 secondsComplete requests: 223877Failed requests: 0Keep-Alive requests: 223027Total transferred: 38726471 bytesTotal body sent: 108604595HTML transferred: 0 bytesRequests per second: 3731.24 [#/sec] (mean)Time per request: 13.400 [ms] (mean)Time per request: 0.268 [ms] (mean, across all concurrent requests)Transfer rate: 630.31 [Kbytes/sec] received 1767.63 kb/s sent 2397.94 kb/s totalConnection Times (ms) min mean[+/-sd] median maxConnect: 0 0 0.5 0 34Processing: 9 13 3.8 13 164Waiting: 8 13 3.8 13 164Total: 9 13 3.8 13 164Percentage of the requests served within a certain time (ms) 50% 13 66% 14 75% 14 80% 14 90% 15 95% 17 98% 22 99% 26 100% 164 (longest request)从测试后果，咱们能够看到
- 在50个并发申请的状况下，申请60秒，均匀每秒能够解决3731次（也就是说，客户端在这种压力下，看到的QPS为3731）
- 均匀每次申请解决的Latency为13.4ms
- 因为开启了keep-alive，连贯简直不耗时间
- 99%的申请都在26ms内实现，最长的申请是164ms
应用腾讯云主机测试后果如下
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Software Foundation, https://www.apache.org/Benchmarking ap-shanghai.cls.myqcloud.com (be patient)Completed 30000 requestsCompleted 60000 requestsCompleted 90000 requestsCompleted 120000 requestsCompleted 150000 requestsCompleted 180000 requestsCompleted 210000 requestsCompleted 240000 requestsCompleted 270000 requestsCompleted 300000 requestsFinished 300000 requestsServer Software: openrestyServer Hostname: ap-shanghai.cls.myqcloud.comServer Port: 80Document Path: /logDocument Length: 0 bytesConcurrency Level: 50Time taken for tests: 40.095 secondsComplete requests: 300000Failed requests: 0Keep-Alive requests: 298850Total transferred: 51894250 bytesTotal body sent: 145500000HTML transferred: 0 bytesRequests per second: 7482.21 [#/sec] (mean)Time per request: 6.683 [ms] (mean)Time per request: 0.134 [ms] (mean, across all concurrent requests)Transfer rate: 1263.94 [Kbytes/sec] received 3543.82 kb/s sent 4807.77 kb/s total Connection Times (ms) min mean[+/-sd] median maxConnect: 0 0 0.1 0 6Processing: 4 7 2.9 6 157Waiting: 4 7 2.9 6 157Total: 4 7 2.9 6 157Percentage of the requests served within a certain time (ms) 50% 6 66% 7 75% 7 80% 8 90% 9 95% 10 98% 14 99% 18 100% 157 (longest request)从后果咱们能够看到，QPS是非腾讯云主机的2倍，为7482
wrk
wrk是一个用来做HTTP benchmark测试的工具。能够产生显著的压力。
装置
apt-get install libssl-devgit clone https://github.com/wg/wrk.gitcd wrkmakecp wrk /usr/sbin应用示例
wrk -c 50 -d 60 -t 5 -s /tmp/wrk_post.lua http://ap-shanghai.cls.myqcloud.com申请的内容在/tmp/wrk_post.lua中规定，有5个线程，开启的连贯有50个，运行60秒
其中/tmp/wrk_post.lua中的内容是
request = function() mypath = "/tmp/post_data.txt"; local file = io.open(mypath, "r"); assert(file); local body = file:read("*a"); -- 读取所有内容 file:close(); wrk.body = body path = "/log" wrk.headers["Content-Type"] = "application/x-protobuf" wrk.headers["Host"] = "ap-shanghai.cls.myqcloud.com" wrk.headers["Authorization"] = "q-sign-algorithm=sha1&q-ak=AKIDMfonbuXfqpcFicn3YrzwivMelfNwFWcW&q-sign-time=1517472219;1517493819&q-key-time=1517472219;1517493819&q-header-list=content-type;host&q-url-param-list=&q-signature=4a4ed6ddc8ba1dfea73d2bee62def9dce8b0ca3c" return wrk.format("POST", path)end后果剖析
Running 1m test @ http://ap-shanghai.cls.myqcloud.com 5 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 15.91ms 25.52ms 880.85ms 98.05% Req/Sec 745.32 105.11 848.00 94.79% 221561 requests in 1.00m, 36.55MB readRequests/sec: 3688.17Transfer/sec: 623.03KB从测试后果，咱们能够看到
- 在5个并发申请的状况下，开启50个连贯，申请60秒，均匀每秒能够解决3688次（也就是说，客户端在这种压力下，看到的QPS为3688）
- 均匀每次申请解决的Latency为15.91ms
应用腾讯云主机测试后果如下
Running 1m test @ http://ap-shanghai.cls.myqcloud.com 5 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 6.77ms 3.42ms 90.45ms 94.82% Req/Sec 1.53k 119.04 1.74k 79.27% 457574 requests in 1.00m, 75.48MB readRequests/sec: 7623.03Transfer/sec: 1.26MB从后果咱们能够看到，QPS是非腾讯云主机的2倍，为7623
总结
以上就是用开源的benchmark工具来从客户端的角度来掂量所能获取的QPS以及Latency。但从客户端看到的性能会受到各种因素的影响，例如申请的形式，本机的资源（CPU，内存，网络），CLS的网络情况，CLS的负载等都会影响客户端看到的性能指标。须要依据理论状况来查看性能瓶颈是来自于CLS还是来自于本机。
参考：
- 应用ab和wrk对OSS进行benchmark测试
记得帮我点赞哦！
精心整顿了计算机各个方向的从入门、进阶、实战的视频课程和电子书，依照目录正当分类，总能找到你须要的学习材料，还在等什么？快去关注下载吧！！！
朝思暮想，必有回响，小伙伴们帮我点个赞吧，非常感谢。
我是职场亮哥，YY高级软件工程师、四年工作教训，回绝咸鱼争当龙头的斜杠程序员。听我说，提高多，程序人生一把梭
如果有幸能帮到你，请帮我点个【赞】，给个关注，如果能顺带评论给个激励，将不胜感激。
职场亮哥文章列表：更多文章
自己所有文章、答复都与版权保护平台有单干，著作权归职场亮哥所有，未经受权，转载必究！