最近测试过程中,遇到两次tps压不上去问题
第一次是:阿里云上采用容器化部署,接口300个并发应用cpu的利用率很低,接口响应时间也很长。,因为接口逻辑非常简单,故研发怀疑是网络问题导致的。
经过一系列排查,是因为购买的是阿里云最基础的slb服务,对每个应用的带宽使用有限制,导致并发量大的时候,接口请求会在slb排队等待,故导致应用的cpu资源没有被利用,将基础的slb服务换成专线网络,并发迅速提升并且应用的cpu也随升高,接口响应时间也降低。
第二次是:接口只能压到100tps,查看应用和DB的资源占用率都不高,接口相应时间也很长,查看活跃的线程数量,只有100,故让研发增大线程数量,tps也随之提升。
额外:
容器化部署在测试过程中发现,单个pod的内存升高无法降低,因为此内存监控不是jvm的监控,通过命令查看jvm的内存监控正常,最后发现是pod打印日志频繁,写日志时候有缓存导致将内存写满,不是日志写满,因为日志是写在磁盘上面的。
容器化部署与性能优化:网络限制与线程配置的影响
博客讲述了在阿里云上进行容器化部署时遇到的两个性能瓶颈问题。第一次问题在于基础SLB服务的带宽限制导致接口响应慢,升级为专线网络后性能显著提升。第二次问题则是接口并发量受限于线程数量,增加线程数后,tps得以提升。此外,还提到单个pod内存升高的原因在于日志缓存,而非日志文件大小,调整日志策略解决了该问题。
9017

被折叠的 条评论
为什么被折叠?



