性能测试实战(十):全链路性能测试

一、全链路性能测试实际情况

真正的全链路性能测试,一般的公司,没有这个技术,因此落地不了

真正的全链路,需要通过浏览回放的平台,把生产的流量(完全可以真实的模拟生产业务并发配比)。但是这个平台,暂时,还没有通用的平台,都是公司自己内部研发,然后使用。个性化的定制,所以需要公司有比较强的测开能力。

我们现在的办法,通过生产流量的监控,用jmeter模拟配比

发起性能测试,现有的工具进行二次开发,与流量回放平台结合,也需要比较强的测开能力

全链路的监控,我们的被测服务器上的所有服务以及资源,都需要被监控,这些监控需要能几乎实时展示出来(serveragent+nmon+infludb+prometheus监控),但也有不足,还需要更细的监控,因此还需要进一步开发(如基于pinpoint\skywalking)。

全链路的分析,需要监控的数据+服务器的知识+分析的经验积累,因此中小微企业很难落地

如果真正要实现,基本上离不开以下步骤:

1、使用jmeter先做单接口

2、业务接口

3、多业务接口

4、逐步监控这些服务

5、所有业务都有性能测试脚本、场景、监控

6、这才慢慢趋近于全链路性能测试

二、全链路性能测试

1、全链路

涉及所有请求,以及服务的调用路径的性能都要被测试到

jmeter做性能测试,我们先做负载测试,找到接口的最大可接受的并发用户数

就可以用这个最大并发用户数去做性能测试,并得到性能指标

可能需要做压力测试,有不稳定的情况

但是混合场景,是很可能要做的,因此,我们生产的环境,肯定是不同数量的人,对不同的业务发起情况,这个需要依据生产流量

性能测试实战(十):全链路性能测试_第1张图片

2、jmeter性能测试场景

(1)线程数

即模拟人数,受到电脑资源限制,jmeter默认使用1g资源,大概能产生1500-2000左右的并发用户数(http协议),超过2000则可能产生不了

线程数:设置多少合适?(需要先做负载测试,并得到这个值)

        引入插件jpgc(插件管理 -》 avallable 搜索 jpgc

                Stepping Thread Group 逐步增加并发用户数  --负载测试

                add 10/30second  using 5 second  每5秒增加10个,运行30

                then hold load for 60 second 结束后持续运行60秒

                Active Threads Over Time 随着时间变化的活跃线程数图

                Response Times Over Time  随着时间变化的响应时间图,类似心电图

                Transaction per Second :TPS

        如何判断最大可接受的并发用户数?

                1、看tps是都有连续的报错,如果有则分析是否是性能问题

                2、看平均时间是否超过1.5秒

                3、看tps有没有明显下降趋势

        粗略算一下50个并发用户数的情况

性能测试实战(十):全链路性能测试_第2张图片

         性能测试实战(十):全链路性能测试_第3张图片

 性能测试实战(十):全链路性能测试_第4张图片

         看tps和平均响应时间两的判断结果

                性能测试实战(十):全链路性能测试_第5张图片

         聚合报告

性能测试实战(十):全链路性能测试_第6张图片

 

(2)相关设置

Read Up时间:指的是启动所有线程数需要的时间,但不代表每秒会产生并发用户数

        产生100用户,差不多用1-2秒就可以了

        100-500用户,差不多2-3秒

        500以上,差不多5-10秒

循环次数:是每个线程数都会运行的次数(大于等于1),一般设置为永远

调度器:需要循环次数勾选永远,才有效

持续时间:一般设置十几秒到几分钟,最多设置半小时

你可能感兴趣的:(性能测试,性能测试)