一次简单的压力测试实例()

https://www.cnblogs.com/imyalost/p/7733386.html

1、性能测试需求

响应时间 ≤20S
网络环境 公司100M内网
压测环境 生产环境压测:模拟综合业务场景
业务场景 库存查询功能由后台迁移至移动端:后台有800个查询入口,移动端变为6400个入口
服务器配置 云服务器

2、需求分析

需求如上,性能测试最关注的三个指标分别是:响应时间、TPS、资源使用情况。

根据需求来看,要求响应时间不能超过20S的前提下,通过压力测试得到服务器的最大处理能力;且只是一个库存查询功能,因为是在线上压测,所以业务场景可以保证是真实可靠的。

3、场景建模

压测环境是生产环境,所以交叉的业务场景较复杂,库存查询功能是针对云服务器,其他的部分业务是通过应用服务器到数据库的,且数据库做了读写分离,故暂不考虑数据库的性能问题。

4、测试数据准备

测试数据的来源一般有这几种方式:

①、将生产的数据完全备份过来:优点是完全真实可靠,不足之处在于测试数据在测试中容易造成数据污染,最好进行数据隔离,以尽量保证数据的可用性。

②、通过模拟业务场景跑脚本或者调度任务来产生数据:在测试数据量不大的情况下可以通过这种方式来准备测试数据。

这里的前提是在测试环境进行压力测试,而本次的压测是直接在生产环境,故测试数据的问题已经算是解决了。

5、脚本开发&调试

测试工具是jmeter,因为只针对查询库存的功能,故只需要进行单接口压测即可。

利用测试工具设计测试脚本的好处是省却了很多繁琐的过程,脚本的调试,首先需要进行接口测试,保证测试的接口是正确可用,然后进行单接口基准测试,最后进行压力测试。

6、脚本执行&记录监控

脚本执行:

在脚本执行过程中,需要由小到大逐渐加大并发数,且记录每次的测试结果,由于网络等情况影响,最好的办法是同一并发数执行多次测试,然后加权平均到的的数值相对来说较可靠。

通过记录不断加压测试后的测试数据,可以观察到响应时间、TPS、资源使用情况等数值的变化,然后进行分析。

记录监控:

每次测试执行的结果进行记录,监控数据库响应时间、连接数,服务器内存、磁盘使用等数值。

PS:由于是在生产环境直接压测,故需要实时监控,以免压测造成服务宕机等严重情况(我执行测试时候开发随时待命,准备重启服务和扩容233)。

性能测试最重要的三个数值:响应时间、TPS、内存、磁盘使用率————监控(jmeter插件、serveragent)

关于jmeter插件:serveragent的使用,后续的博客会进行介绍。

7、结果分析&瓶颈定位

通过上面测试得到的测试数据,可以进行针对性的分析,比如在压测过程中,资源、内存、连接数等是否使用饱和,是否有线程等待,数据库响应时间等,然后利用排除法优先级进行调优。

排除法:针对可能影响到性能的几个因素,一个个分析排除;

优先级:根据实际情况,对调优的投入和时间等需要花费的时间和资源进行评估,排优先级,选择最合适的方案。

8、调优&验证

关于调优,我本人技术比较薄弱,就不献丑了,说说我自己知道的一些调优方法:

内存、磁盘:简单粗暴的做法,直接加服务器吧。。。

数据库:更改配置的连接数,加索引、读写分离、分库、分区、分表、物理视图等手段。。。

连接池:优化连接池配置,增加连接数等,具体请看链接博客的介绍。。。

前端:减少请求连接,数据包尽量放在body中,图片压缩、异步加载、JavaScript脚本放在HTML最后等等手段,具体请看链接博客的介绍。。。

末尾:性能测试水太深,我们公司的性能测试,只能说小打小闹,真正的性能测试,也就大公司做得起(性能测试投入成本很大),大公司有这个需求(小公司哪来的线上流量。。。)。

推荐大家几篇博客,了解下阿里的全链路压测、饿了么全链路压测。

————————

https://www.cnblogs.com/imyalost/p/7733386.html

1、性能测试需求

响应时间 ≤20S
网络环境 公司100M内网
压测环境 生产环境压测:模拟综合业务场景
业务场景 库存查询功能由后台迁移至移动端:后台有800个查询入口,移动端变为6400个入口
服务器配置 云服务器

2、需求分析

需求如上,性能测试最关注的三个指标分别是:响应时间、TPS、资源使用情况。

根据需求来看,要求响应时间不能超过20S的前提下,通过压力测试得到服务器的最大处理能力;且只是一个库存查询功能,因为是在线上压测,所以业务场景可以保证是真实可靠的。

3、场景建模

压测环境是生产环境,所以交叉的业务场景较复杂,库存查询功能是针对云服务器,其他的部分业务是通过应用服务器到数据库的,且数据库做了读写分离,故暂不考虑数据库的性能问题。

4、测试数据准备

测试数据的来源一般有这几种方式:

①、将生产的数据完全备份过来:优点是完全真实可靠,不足之处在于测试数据在测试中容易造成数据污染,最好进行数据隔离,以尽量保证数据的可用性。

②、通过模拟业务场景跑脚本或者调度任务来产生数据:在测试数据量不大的情况下可以通过这种方式来准备测试数据。

这里的前提是在测试环境进行压力测试,而本次的压测是直接在生产环境,故测试数据的问题已经算是解决了。

5、脚本开发&调试

测试工具是jmeter,因为只针对查询库存的功能,故只需要进行单接口压测即可。

利用测试工具设计测试脚本的好处是省却了很多繁琐的过程,脚本的调试,首先需要进行接口测试,保证测试的接口是正确可用,然后进行单接口基准测试,最后进行压力测试。

6、脚本执行&记录监控

脚本执行:

在脚本执行过程中,需要由小到大逐渐加大并发数,且记录每次的测试结果,由于网络等情况影响,最好的办法是同一并发数执行多次测试,然后加权平均到的的数值相对来说较可靠。

通过记录不断加压测试后的测试数据,可以观察到响应时间、TPS、资源使用情况等数值的变化,然后进行分析。

记录监控:

每次测试执行的结果进行记录,监控数据库响应时间、连接数,服务器内存、磁盘使用等数值。

PS:由于是在生产环境直接压测,故需要实时监控,以免压测造成服务宕机等严重情况(我执行测试时候开发随时待命,准备重启服务和扩容233)。

性能测试最重要的三个数值:响应时间、TPS、内存、磁盘使用率————监控(jmeter插件、serveragent)

关于jmeter插件:serveragent的使用,后续的博客会进行介绍。

7、结果分析&瓶颈定位

通过上面测试得到的测试数据,可以进行针对性的分析,比如在压测过程中,资源、内存、连接数等是否使用饱和,是否有线程等待,数据库响应时间等,然后利用排除法优先级进行调优。

排除法:针对可能影响到性能的几个因素,一个个分析排除;

优先级:根据实际情况,对调优的投入和时间等需要花费的时间和资源进行评估,排优先级,选择最合适的方案。

8、调优&验证

关于调优,我本人技术比较薄弱,就不献丑了,说说我自己知道的一些调优方法:

内存、磁盘:简单粗暴的做法,直接加服务器吧。。。

数据库:更改配置的连接数,加索引、读写分离、分库、分区、分表、物理视图等手段。。。

连接池:优化连接池配置,增加连接数等,具体请看链接博客的介绍。。。

前端:减少请求连接,数据包尽量放在body中,图片压缩、异步加载、JavaScript脚本放在HTML最后等等手段,具体请看链接博客的介绍。。。

末尾:性能测试水太深,我们公司的性能测试,只能说小打小闹,真正的性能测试,也就大公司做得起(性能测试投入成本很大),大公司有这个需求(小公司哪来的线上流量。。。)。

推荐大家几篇博客,了解下阿里的全链路压测、饿了么全链路压测。