平台基于Netty构建了高性能的API网关,支持HTTP、Restful、TCP等的接入和消息路由。当性能压测到4000 QPS一段时间后,发现性能急剧下降,最低时到0,停止压测一段时间,系统恢复,再压测一段时间,用户并发量大了之后,性能又急剧下降,形成周期性波动,吞吐量非常不稳定。
【服务端代码】
压测一段时间之后,发现内存和CPU占用飙升,同时QPS下降,客户端停止压测一段时间,CPU占用降低,内存占用恢复正常,
在压测过程中,当吞吐量下降、CPU占用飙升时,采集线程堆栈,发现GC线程占用大量 CPU资源,堆栈如图6-3所示(需要采集线程CPU占用相关数据,此处省略)。
![](https://i-blog.csdnimg.cn/blog_migrate/0576a524d36673b6f067245a12532e08.png)
通过监控数据分析,发现性能波动与内存占用情况强相关,当内存占用比较高时,GC线程忙于内存回收,抢占大量CPU资源,而且在GC过程中也会导致应用线程暂停(不同的GC收集器,暂停策略不同),最终造成吞吐量急剧下降。但是当停止压测或者并发请求量降低之后,服务端还可以恢复,说明并不存在真正的内存忘记释放导致的泄漏问题。
问题分析:
结合代码分析发现,API网关每次收到请求消息,无论请求消息大还是小,哪怕只有100字节,都会构造一个默认为64KB的char数组,用于处理和转发请求消息。如果后端转发消息较慢,就会导致任务队列积压,由于每个任务(Runnable,此处为Lambda表达式)持有一个64KB的char数组,所以积压多了就会转移到老年代,一旦触发老年代GC,耗时太长系统吞吐量就变为0了。
优化后的代码:
![](https://i-blog.csdnimg.cn/blog_migrate/a3bdd0636e951a98c203f94a36a43d4a.png)
【网关类产品的优化建议】
网关类产品的主要功能就是消息的预处理和转发,请求和响应对象都是“朝生夕灭”类型的,在高并发场景下,一定要防止不合理的内存申请,具体措施如下。
(1)
内存按需分配。不要一次性申请较大的内存来保存较小的消息,造成内存空间浪费,引发频繁GC问题。
(2)
不要频繁地创建和释放对象。这会增加GC的负担,降低系统的吞吐量,可以采用内存池等机制优化内存的申请和释放。
(3)
减少对象拷贝。对于透传类的消息,尽量把涉及业务逻辑处理的字段放入Header,不要对Body做解码,直接透传到后端服务即可。这样可以大幅减少内存的申请和对象拷贝,降低内存占用,提升性能。
(4)
流控机制必不可少。除了客户端并发连接数流控、QPS流控,还需要针对内存占用等指标做流控,防止业务高峰期的OOM。