1 背景 随着业务的快速成长,日访问量越来越高,除了对功能要求很高以外,对性能要求也越来越高。 在实际工作中,我们往往会被一些问题所困扰。 1)线上服务容量是多少?性能痛点在哪里? 可伸缩性(resilience)和可靠 ...
1 背景
随着业务的快速成长,日访问量越来越高,除了对功能要求很高以外,对性能要求也越来越高。 在实际工作中,我们往往会被一些问题所困扰。
1)线上服务容量是多少?性能痛点在哪里? 可伸缩性(resilience)和可靠性(reliability)怎样?预先知道了系统的容量,做到心中有数,才能为最终规划整个运行环境的配置提供有利的依据。
2)新开发的功能是否满足性能指标? 重新修改的代码会不会带来性能问题? 对服务或工具的参数修改是否有效果(如jvm参数,mysql或solr配置等)? 如果在上线用前就能进行验证,那么不仅能极大降低部署时发生意外的概率,还能为性能优化提供指导。
2 现状
为尝试解决上述问题,我们在多个项目上进行过性能测试,使用过的方法主要分成三类。
方案 | 具体方式 | | 优点 | 缺点 |
人为模拟请求 | 自己写代码或者使用简单的工具如httpload等去模拟用户请求进行测试 | | 操作简单,能快速的得到cpu、mem、 load、 qps等极限值。 | 缺少真实用户交互行为,缺乏真实性 |
copy线上流量 | 使用tcpcopy工具实时copy线上流量到某台机器 | | 操作简单,是真实线上请求,且对线上服务压力无影响 | 需要准备一套跟线上机器配置、依赖一致的独立环境,同时如果是服用线上的环境的话,一些写操作的请求被copy会有问题 |
线上流量切换 | 直接用线上的机器和环境,通过调整nginx配置参数,逐渐将要做压测的机器的权重增加,然后观察该机器各个指标性能 | | 真实生产线流量,能把用户行为导向压测服务器,是最为真实的用户行为,能够把一些需要登陆,有用户交互行为的性能真实的反映出来 | 因为是用生产系统真实流量来模拟压测,无法得出最大值,如果阀值设置有误,也存在一定的风险。此外该性能测试也不能经常进行 |
3 存在的不足
尽管我们在性能测试上做过一些尝试,但还远远不够,存在以下不足。
3.1 性能测试指标和标准尚未完全确立
不同服务测试指标应该不同,相应的标准也不同,例如接入层服务和后端服务指标是不同的。如果我们能为各个服务制定类似如下的标准,以后再进行性能测试就有了参考依据。 随着服务的发展,这些标准也会随之相应改动,要求会越来越严格。
判断指标 | 不通过的标准 |
超时概率 | 大于万分之一 |
错误概率 | 大于万分之一 |
平均响应时间 | 超过100ms |
0.99响应时间 | 超过200ms |
qpm(每分钟处理的请求量) | 小于2w |
qpm波动范围(标准差) | 正负3 |
cpu使用率 | 平均每核超过75% |
负载(load) | 平均每核超过1.5 |
jvm内存使用率 | 大于80% |
gc平均时间 | 超过1s |
fullgc频率 | 频率高于半小时一次 |
... | ... |
原标题:容量预估/性能压测思考
关键词:
*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们:
admin#shaoqun.com
(#换成@)。