在 tomcat 接到请求之后,每个请求会再发送几个请求给不同的下游服务,然后主线程使用
public boolean await(long timeout, TimeUnit unit)等待请求完成,这里会根据算出来一个超时时间,防止 response 超时,但是实际的等待时间会比设置的时间多 50-100 毫秒(目前没有统计超过的占比数据,保守估计超时占比在 5%以下)
因为流量比较大,一天经过这个 await 方法的次数应该不到 60 亿(tomcat 数量不少),所以这种超时总量其实是不少的,能优化一点是一点(同时也能提升自己的技术水平)
上图是我问了 ChatGPT 之后,以我现在的知识水平来讲,我觉得是 GC 导致的,于是我看了其中一个 tomcat 的 GC 情况
我们目前使用的是 openJDK17,G1 的垃圾回收器,以及一些虚拟机参数应该也很久不变了(我认为是有优化空间的),比如 jkd17 是有 ZGC 的,之前查看 ZGC 的 world stop 时间会减少很多
验证是否是 GC 导致的方法,我想到的是记录 await 超时的时间戳和不超时的时间戳,分开统计,然后再记录 GC 的开始时间和结束时间,查看在 GC 这个时间段内的是否超时的时间戳占比大,这种验证方法可行么?
最后有大佬遇到过这种问题么?或者有没有别的思路解决这个问题
