压力测试总结
最近学习了如何做压力测试，所以这里总结一下压力测试所需要的工具、如何选择压力测试的参考对象和目标对象，还有如何提取压力测试结果的重要信息，最后依据这些信息选择不同的优化方案
什么是压力测试
压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试应用，来测试被测系统的性能、可靠性、稳定性等。
压力测试的意义
压力测试的结果包括单位时间响应次数、平均响应时间，最长响应时间和最短响应时间等数据，这些数据能作为如何优化项目重要的参考依据。
压力测试工具
Siege
- 基本用法: siege -c100 -t1 -b http://localhost:3000，测试指定url，可以获取到该url的压测结果
- 参数解释:
- -c表示并发数，
- -t表示压测时间，
- 更多参数解释可以访问 https://www.joedog.org/siege-manual/
- 输出结果
Transactions: 13 hits //完成13次处理
Availability: 100.00 % //成功率100%
Elapsed time: 59.26 secs //总共使用时间
Data transferred: 0.03 MB //共数据传输0.03MB
Response time: 4.22 secs //响应时间，显示网络连接的速度
Transaction rate: 0.22 trans/sec //平均每秒完成 0.22 次处理
Throughput: 0.00 MB/sec //平均每秒传送数据
Concurrency: 0.93 //实际最高并发连接数
Successful transactions: 13 //成功处理次数
Failed transactions: 0 //失败处理次数
Longest transaction: 6.36 //每次传输所花最长时间
Shortest transaction: 3.19 //每次传输所花最短时间
- 结果中的关键数据是
- Transaction rate，这代表Request per second，这个数字越高，表示服务器的每秒处理能力越高
- Failed transactions，如果出现非0数字，表示服务器开始出现无法响应的情况
压力测试的对象选择
参考对象
- 一个静态页面的url目的是为了测试os server+http server，目标对象的测试结果越接近这个的测试结果是最理想的。在rails项目中就是放在public目录下的静态页面。
- 一个简单不带复杂业务逻辑的、也不带数据库查询的app页面的url，目的是为了测试os server+http server+app server ，优化结果越接近这个的测试结果越好。在rails项目中就是，需要Rails路由匹配且不带layout的静态页面
参考对象1 可以选择404页面。符合 参考对象2 的页面一般是不存在的，因为这样的页面通常都会被放在public目录下，所以需要特意创建一个这样的页面。
目标对象
- 静态路由：如首页（localhost:3000）、About页面（localhost:3000/about）
- 动态路由：如文章详细页面（localhost:3000/articles/:id）
目标对象的平均响应时间越接近 参考对象1代表页面的优化程度越高。
压力测试结果分析
测试样例
benchmarking result@2016-06-29 15:00:56 +0800
- concurrence: 100
- times: 3min
benchmarking result@2016-06-29 16:05:38 +0800
- concurrence: 200
- times: 3min
benchmarking result@2016-06-29 11:18:09 +0800
- concurrence: 300
- times: 3min
benchmarking result@2016-06-29 16:44:50 +0800
- concurrence: 400
- times: 3min
结果分析
-
极限响应并发数：300
极限并发数是项目平均响应时间最短的页面能稳定响应请求的并发数，它的值可取 参考对象1在测试中出现Failed占比低于0.1%的最大并发数。
-
Web server的RPS：152
Web server的RPS是项目在极限响应并发数下Web server每秒能处理的请求数，它的值取自测试样例的 html page 在Trans rate列的值
-
App server的RPS：30
App server的RPS是项目在极限响应并发数下App server每秒处理的请求数，由于测试样例中存在多个App server page，所以这里取测试样例中app server page中Trans rate最低的一个，这个例子里的是 article_detail_page 的Trans rate 约30
-
项目可支持每日访问量范围：1728000 ~ 13132800
项目可支持每日访问量范围的下限是App server的RPS的值乘以16小时（假设常规用户是从早上8:00到晚上12点在线）的秒数，项目可支持每日访问量范围的上限是Web server的RPS的值乘以24小时的秒数，可以得出项目可支持每日访问量范围是
1728000(30 * 16 * 60 * 60) ~ 13132800 (152 * 24 * 60 * 60)
优化方案
根据压力测试的结果给出优化建议是压力测试的意义所在。以下列出一些压测的结果和通常情况下相应的优化方案，具体还要视项目的具体情况选择优化方案。
- 目标对象的页面内容不需要即时更新。这种情况可以使用page caching，并使用cornjob设置定时清除缓存命令。
- 目标对象是一个很少改动，但改动后页面内容需要即时更新。这种情况可以使用action caching，并且在相关内容修改后清除缓存。
- 目标对象经常改动，并且改动后页面内容需要即时更新的。这种情况可以使用fragment caching，这是最简单的缓存策略，不需要配置缓存失效的操作
- 项目预期访问并发的峰值大于极限可响应并发数。这种情况就不能从代码上解决问题了，而是需要升级服务器，搭建负载均衡等从服务器方面入手的方案