周一项目经理给我提了一个性能测试需求:对库存查询功能迁移后的服务器处理能力作一次压力测试,下班到家给测试群的小伙伴提及这事,引发了一些讨论。。。html
紫川(我建的测试交流群的某个咸鱼)吐槽我写性能测试博客一直不写实际操做方法,个人回答是:最好的学习方法是跟着学、照着作,思考咨询总结实践。。。前端
只是截图表示操做过程,是没多大参考意义的,思考分析的方法和思惟更重要(这种思考分析的方法须要练习和知识的积累)。。。数据库
习惯将本身成长的收获进行记录,这篇博客就记录下本身在此次压测过程当中的分析方法和操做过程。。。服务器
一、性能测试需求网络
响应时间 | ≤20S |
网络环境 | 公司100M内网 |
压测环境 | 生产环境压测:模拟综合业务场景 |
业务场景 | 库存查询功能由后台迁移至移动端:后台有800个查询入口,移动端变为6400个入口 |
服务器配置 | 云服务器 |
二、需求分析并发
需求如上,性能测试最关注的三个指标分别是:响应时间、TPS、资源使用状况。app
根据需求来看,要求响应时间不能超过20S的前提下,经过压力测试获得服务器的最大处理能力;且只是一个库存查询功能,由于是在线上压测,因此业务场景能够保证是真实可靠的。异步
三、场景建模工具
压测环境是生产环境,因此交叉的业务场景较复杂,库存查询功能是针对云服务器,其余的部分业务是经过应用服务器到数据库的,且数据库作了读写分离,故暂不考虑数据库的性能问题。性能
四、测试数据准备
测试数据的来源通常有这几种方式:
①、将生产的数据彻底备份过来:优势是彻底真实可靠,不足之处在于测试数据在测试中容易形成数据污染,最好进行数据隔离,以尽可能保证数据的可用性。
②、经过模拟业务场景跑脚本或者调度任务来产生数据:在测试数据量不大的状况下能够经过这种方式来准备测试数据。
这里的前提是在测试环境进行压力测试,而本次的压测是直接在生产环境,故测试数据的问题已经算是解决了。
五、脚本开发&调试
测试工具是jmeter,由于只针对查询库存的功能,故只须要进行单接口压测便可。
利用测试工具设计测试脚本的好处是省却了不少繁琐的过程,脚本的调试,首先须要进行接口测试,保证测试的接口是正确可用,而后进行单接口基准测试,最后进行压力测试。
六、脚本执行&记录监控
脚本执行:
在脚本执行过程当中,须要由小到大逐渐加大并发数,且记录每次的测试结果,因为网络等状况影响,最好的办法是同一并发数执行屡次测试,而后加权平均到的的数值相对来讲较可靠。
经过记录不断加压测试后的测试数据,能够观察到响应时间、TPS、资源使用状况等数值的变化,而后进行分析。
记录监控:
每次测试执行的结果进行记录,监控数据库响应时间、链接数,服务器内存、磁盘使用等数值。
PS:因为是在生产环境直接压测,故须要实时监控,以避免压测形成服务宕机等严重状况(我执行测试时候开发随时待命,准备重启服务和扩容233)。
性能测试最重要的三个数值:响应时间、TPS、内存、磁盘使用率————监控(jmeter插件、serveragent)
关于jmeter插件:serveragent的使用,后续的博客会进行介绍。
七、结果分析&瓶颈定位
经过上面测试获得的测试数据,能够进行针对性的分析,好比在压测过程当中,资源、内存、链接数等是否使用饱和,是否有线程等待,数据库响应时间等,而后利用排除法和优先级进行调优。
排除法:针对可能影响到性能的几个因素,一个个分析排除;
优先级:根据实际状况,对调优的投入和时间等须要花费的时间和资源进行评估,排优先级,选择最合适的方案。
八、调优&验证
关于调优,我本人技术比较薄弱,就不献丑了,说说我本身知道的一些调优方法:
内存、磁盘:简单粗暴的作法,直接加服务器吧。。。
数据库:更改配置的链接数,加索引、读写分离、分库、分区、分表、物理视图等手段。。。
链接池:优化链接池配置,增长链接数等,具体请看连接博客的介绍。。。
前端:减小请求链接,数据包尽可能放在body中,图片压缩、异步加载、JavaScript脚本放在HTML最后等等手段,具体请看连接博客的介绍。。。
末尾:性能测试水太深,咱们公司的性能测试,只能说小打小闹,真正的性能测试,也就大公司作得起(性能测试投入成本很大),大公司有这个需求(小公司哪来的线上流量。。。)。