我遇到的性能压测问题集合（持续更新中）

  在测试中，接触到性能压测，过程中遇到了很多性能问题，初遇性能测试时，对于我来说，性能测试简直就是另一个宇宙；下面列出了我在性能测试中的一些问题疑惑，以及我找到的答案。

1、全链路压测是什么？
全链路压测，是基于真实的生产环境来模拟海量的并发用户请求和数据，对整个业务链路进行压力测试，试图找到所有潜在性能瓶颈点并持续优化的实践。例如：乘客发单，0-3 分钟内派给附近的司机，司机抢单后，去接乘客，到达目的地；双十一活动模拟用户登录购买商品到下单的全流程；

2、为什么要进行全链路压测？
原因在于真实的业务场景下，每个系统的压力都比较大，而系统之间是有相互依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况，会引入一个不确定的误差。这就好比，我们要生产一个仪表，每一个零件都经过了严密的测试，最终把零件组装成一个仪表，仪表的工作状态会是什么样的并不清楚。因此需要进行全链路压测。
—我们平时进行的是单个接口的压测，可以先单个接口压测在进行全链路压测,先保障单接口满足性能要求，再去考虑全链路

3、全链路压测的难点有什么？
3.1、海量并发请求的发起；
3.2、全链路压测流量的隔离；
3.3、实际业务负载的模拟；因为真实的场景远比我们想的要复杂
3.4、测试完成后的数据清理。我们公司压测后的数据清理？？？删库

4、容量规划四步走？
4.1. 业务流量预估阶段：通过历史数据分析未来某一个时间点业务的访问量会有多大；
4.2. 系统容量评估阶段：初步计算每一个系统需要分配多少机器；
4.3. 容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整；------我们压测的目的
4.4. 流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务。

5、如何计算压测的机器的大小？
5.1、最小机器数 ＝ 预估的业务访问量 ／ 单机能力。
5.2、单机能力的测试方法：
5.2.1 模拟请求：通过对生产环境的一台机器发起模拟请求调用来达到压力测试的目的
----我们压测的就是模拟请求，模拟请求的缺点在于，模拟请求和真实业务请求之间存在的差异，会对压力测试的结构造成影响
5.2.2：复制请求：通过将一台机器的请求复制多份发送到指定的压测机器
5.2.3：请求转发：将分布式环境中多台机器的请求转发到一台机
5.2.4：调整负载均衡：修改负载均衡设备的权重，让压测的机器分配更多的请求

6、并发用户数是什么？
指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器 不产生压力，注册用户数一般指的是数据库中存在的用户数。

7、如何获取并发用户数(Vu)？
对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。

8、TPS计算公式：
Vui表示的是第i个脚本使用的并发用户数
Rti表示的是第i个脚本一次完成所有操作的时间，即Action时间
那么第j个事务的TPS = Vui/Rti
话外：业务预估每日在线审批交易量10w笔预估，使用二八原则推算，80%的业务量发生在20%的业务时间（10小时）内，峰值TPS = 10w * 80% / (10 * 0.2 * 3600)，约11.11笔/秒。

9、超限后的流量控制如何做？线上机器是如何超限的？超限后带来的问题是什么？
当一台机器超负荷运转的时候，这台处理请求的时间会变长。这会给用户带来不好的体验，用户会试图重复提交请求，这无形中又给系统带来了更多的请求压力。随着请求堆积的越来越多，系统性能会逐渐下降甚至无法响应新的请求。当一台机器挂掉以后, 负载均衡会把请求重定向到另外的机器上去，这又无形中给别的机器带来了更多的任务，而这些机器也处于一个饱和的状态，很快也会像第一台机器一样，也无法响应新的请求。就这样，在很短的时间之内，越来越多的机器会停止响应，最终导致整个集群都无法响应。这就使我们常常说的“雪崩效应”。一旦“雪崩”发生，就很难停止。我们必须有一个有效的机制，来监控和控制进入的流量，来防止灾难的发生。

10、压测过程中，要观察FGC，那么是什么因素可能导致了FGC？什么样的情况会进入老年代？
FULLGC发生的条件有五种，那么对于压测而言，是什么导致了FUllGC，需要具体问题具体分析。（1）System.gc()方法的调用。（2）旧生代空间不足。（3）Permanet Generation空间满了。（4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存。（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。FullGC并不可怕，频繁调用FullGC，可能会出现问题。
动态对象年龄判定（虚拟机并不会永远地要求对象的年龄都必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor空间中相同年龄的所有对象的大小总和大于Survivor的一半，年龄大于或等于该年龄的对象就可以直接进入老年代）

参考文件
1、《并发用户数与TPS之间的关系》
https://blog.csdn.net/guoyf123321/article/details/80763107
2、《Java面试总结之Full GC》
https://baijiahao.baidu.com/s?id=1632743030610982339&wfr=spider&for=pc
3、《阿里巴巴的全链路压测》
https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/9479739
4、<线程的基本概念>
https://www.cnblogs.com/yangming1996/p/9503911.html
5、<性能测试：深入理解线程数，并发量，TPS，看这一篇就够了>
https://www.cnblogs.com/dayu2019/p/11906855.html

后续需要解决的问题：
1、全链路压测怎么观察监控，如何调整资源