【背景说明】

压测过程中发现链路上所有资源占用都不高，但是吞吐量不稳定，且无大量报错，甚至出现什么都没变的情况下吞吐量差距较大问题。

【问题表现】

同样并发下，没做任何改动，吞吐量出现多种情况，耗时明显过长

【排查思路】

第一次排查链路资源，资源占用正常，没有发现明显问题；第二次排查对链路资源配置情况进行查看，发现云托管服务实例数初值较低，默认为1个（2c4g），怀疑云托管存在存在瓶颈，虽然云托管CPU最多只到了百分之五十，没有达到自动扩容条件（自动扩容设置为百分之六十），但1个实例配置较低，需调到初始后复压

调大初始实例数后为8个后，吞吐量一下就上去了

怀疑一个事例只支持1000吞吐量，于是改小初始事例为4后进行复压，发现资源降配后吞吐量也随即降低下来

本着尽可能节省资源的原则，希望通过云托管本身的扩容机制去触发自动扩容，但实际测试下来发现不尽人意，触发自动扩容较慢，时间较长，无法短时间完成自动扩容，于是只有在满足需求的情况下去设置初始值，触发条件也降低处理（调为CPU占用百分之五十）

【总结】

排查链路时除了需要关注资源负载情况外，还需要注意资源本身的一个分配情况，确定资源使用合理，排除分配资源本身就不合理的情况