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

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

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

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

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

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

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

1、使用jmeter先做单接口

2、业务接口

3、多业务接口

4、逐步监控这些服务

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

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

1、全链路

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

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

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

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

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

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个并发用户数的情况

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

         聚合报告

（2）相关设置

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

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

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

        500以上，差不多5-10秒

循环次数：是每个线程数都会运行的次数（大于等于1），一般设置为永远

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

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