一、全链路性能测试实际情况
真正的全链路性能测试，一般的公司，没有这个技术，因此落地不了
真正的全链路，需要通过浏览回放的平台，把生产的流量（完全可以真实的模拟生产业务并发配比）。但是这个平台，暂时，还没有通用的平台，都是公司自己内部研发，然后使用。个性化的定制，所以需要公司有比较强的测开能力。
我们现在的办法，通过生产流量的监控，用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），一般设置为永远
调度器：需要循环次数勾选永远，才有效
持续时间：一般设置十几秒到几分钟，最多设置半小时
