压测过程中发现链路上所有资源占用都不高,但是吞吐量不稳定,且无大量报错,甚至出现什么都没变的情况下吞吐量差距较大问题。
同样并发下,没做任何改动,吞吐量出现多种情况,耗时明显过长
第一次排查链路资源,资源占用正常,没有发现明显问题;第二次排查对链路资源配置情况进行查看,发现云托管服务实例数初值较低,默认为1个(2c4g),怀疑云托管存在存在瓶颈,虽然云托管CPU最多只到了百分之五十,没有达到自动扩容条件(自动扩容设置为百分之六十),但1个实例配置较低,需调到初始后复压
调大初始实例数后为8个后,吞吐量一下就上去了
怀疑一个事例只支持1000吞吐量,于是改小初始事例为4后进行复压,发现资源降配后吞吐量也随即降低下来
本着尽可能节省资源的原则,希望通过云托管本身的扩容机制去触发自动扩容,但实际测试下来发现不尽人意,触发自动扩容较慢,时间较长,无法短时间完成自动扩容,于是只有在满足需求的情况下去设置初始值,触发条件也降低处理(调为CPU占用百分之五十)
排查链路时除了需要关注资源负载情况外,还需要注意资源本身的一个分配情况,确定资源使用合理,排除分配资源本身就不合理的情况
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。