Servlet 3 性能调优

Servlet 3 早在 2011 年推出,但很多 web 项目还是使用 Servlet 2.5。这些 web 项目业务相对较重、单机负载相对较低,Servlet 2.5 由于更少切换线程比 Servlet 3 更加稳定。

随着微服务的发展,web 层不断演进,涌现出越来越多的 API 网关。API 网关将 web 层的业务剥离开,专注于安全防护和路由转发。这种重 IO 轻 CPU 的场景非常适合使用 Servlet 3。

通常异步 Servlet 项目中有 3 类线程池:Tomcat IO 工作线程池、业务线程池、RPC 线程池。

下面介绍 Servlet 优化的五个阶段,这五个阶段大致分为三类优化手段:线程隔离、无锁处理和更换容器。

第一阶段:纯同步

第一阶段采用同步 Servlet,Tomcat 线程进入业务代码并执行预处理、RPC 调用、结果处理
压测到 1000 QPS 时 AVG(20)、99 线(70)、999 线(75),整体平稳

第二阶段:伪异步

异步 Servlet 中通过 servletRequest.startAsync 开启异步,asyncContext.dispatch 重新分发请求、asyncContext.complete 结束异步。Spring MVC 的异步是先开启异步、执行业务、重新分发请求。这种方式是为了兼容 Spring MVC 的同步实现,但是由于两次分发导致代码更复杂、并可能对 Servlet 带来更大的压力。

在第二阶段的时候采用类似的实现:

  1. Tomcat 线程进入业务代码并预处理请求
  2. Tomcat 线程开启异步并异步请求 RPC 服务
  3. RPC 回调后重新分发请求
  4. Tomcat 线程进入业务代码并处理请求结果

压测到 1000 QPS 时 AVG(18)、99 线(56)、999 线(60),整体平稳,异步占优
压测到 1400 QPS 时 AVG(23)、99 线(80)、999 线(85),整体平稳,异步占优
压测到 2000 QPS 时 AVG(32)、99 线(300)、999 线(320),波动较大

第三阶段:全异步

项目在第三阶段的时候采用全异步:

  1. Tomcat 线程进入业务代码并开启异步
  2. Tomcat 线程提交业务线程并返回
  3. 业务线程预处理并调用 RPC 服务
  4. RPC 回调后提交业务线程
  5. 业务线程处理请求结果并结束异步

压测到 2500 QPS 时 AVG(44)、99 线(83)、999 线(85),整体平稳,时有抖动
压测到 3000 QPS 时 AVG(70)、99 线(180)、999 线(190),整体平稳,时有抖动

第四阶段:异步优化

业界 4 核 8 g 异步 Servlet 的机器吞吐量能够达到 1w+ QPS

1.观察机器在压测时的性能指标,QPS 3000 时出现 full gc

2.压测结束后 Dump 机器内存后发现无大对象,但是有大量 byte [] 和 char [] 对象

3.使用 JProfiler 分析 byte [] 的来源,可能来自 Tomcat 的 IO

在对比 Tomcat 线程数后猜测,可能是 Tomcat 线程池打满所致。同时在 Tomcat 日志中也出现大量队列已满的报错

4.尝试调整 Tomcat 线程池配置:增加线程数量、采用 Http11Nio2Protocol 处理协议。调整后压测吞吐量没有提升。https://renwole.com/archives/357

<Executor
 name="tomcatThreadPool"
 namePrefix="catalina-exec-"
 maxThreads="500"
 minSpareThreads="30"
 maxIdleTime="60000"
 prestartminSpareThreads = "true"
 maxQueueSize = "100"
/>
<Connector
 executor="tomcatThreadPool"
 port="8080"
 protocol="org.apache.coyote.http11.Http11Nio2Protocol"
 connectionTimeout="60000"
 maxConnections="10000"
 redirectPort="8443"
 enableLookups="false"
 acceptCount="100"
 maxPostSize="10485760"
 maxHttpHeaderSize="8192"
 compression="on"
 disableUploadTimeout="true"
 compressionMinSize="2048"
 acceptorThreadCount="2"
 URIEncoding="utf-8"
 processorCache="20000"
 tcpNoDelay="true"
 connectionLinger="5"
 server="Server Version 11.0"
 />

5.修改业务线程池大小
压测到 5000 QPS 时 AVG(59)、99 线(130)、999 线(145),整体平稳

6.修改调用下游服务的方式,基于回调 => 同步

7.对比业务各阶段耗时,增加服务调用线程池线程
压测到 6000 QPS 时高点 AVG(348)、99 线(500)、999 线(1000),整体平稳

8.异步 Servlet 开启异步后超时自动结束请求,RPC 在回调时如果已经超时会报状态异常,因此对 onTimeout 和 onComplete 加上同步锁

9.移除 RPC 调用,mock 服务返回结果
压测到 10000 QPS 时高点 AVG(12)、99 线(504)、999 线(1000),CPU 几乎打满

10.调整业务线程组,预处理和调用服务使用同一线程、RPC 回调和处理返回结果使用同一线程,弱化 CPU 轮转。压测到高点时开始出现线程阻塞
压测到 6000 QPS 时高点 AVG(8)、99 线(35)、999 线(1000),CPU 几乎打满

11.缩短 RPC 服务超时时间 200 -> 50
压测到 4000 时开始出现线程阻塞

12.移除 AsyncContext 监听中 onTimeout 和 onComplete 上的同步锁

13.使用 servlet 3.1 nio,注册 reader listener 和 write listener 异步读写

压测到 7000 QPS 时高点 AVG(10)、99 线(30)、999 线(1000)

第四阶段总结:

  1. 异步 IO 能一定程度上提高并发,在传输量不大的情况下提高并不明显
  2. 高并发同步调用会阻塞 IO 线程
  3. Tomcat 内部没有复用 bytebuffer 导致请求量大时新生代 gc 频繁,最后引起服务超时,日志阻塞等一系列问题

第五阶段:Jetty 容器

Jetty 底层对 ByteBuffer 对象的复用和线程池的处理有更好的优化。
在第五阶段,更换 Servlet 容器为 Jetty 进行调优。
压测到 11000 QPS 时高点 AVG(40)、99 线(90)、999 线(140),整体平稳

第五阶段总结:

  1. 在高并发的场景中,Jetty 的性能比 Tomcat 要强,耗时曲线非常平稳
  2. 使用 Jetty 容器后,10000 QPS 时 AVG(5)、99 线(20)、999 线(20

推荐阅读更多精彩内容