在 Spring Boot 中增加 Tomcat 的连接超时答案

【问题标题】：Increasing connection timeout for Tomcat in Spring Boot在 Spring Boot 中增加 Tomcat 的连接超时
【发布时间】：2018-12-03 01:14:24
【问题描述】：

如何增加超时，以便在处理响应之前，请求不会超时？

Spring Boot 中的 Tomcat 设置：

server.tomcat.max-connections=2000
server.tomcat.max-threads=200
server.connection-timeout=1200000

在 15 秒的过程中，每秒请求被提高到 constantUsersPerSec(20) during (15) 到 300，并且所有请求都得到了处理，如下图所示 gatling（蓝色）。

scn.inject(
      constantUsersPerSec(20) during (15), 
    )

这是由于 max-connections = 2000 使用 200 工作线程处理了 300 个请求。

Controller 是用 Spring MVC 编写的，它返回 DeferredResult，它会进行异步请求处理，因此一旦处理完响应就会恢复响应。

但即使 server.connection-timeout 设置为高数 1200000 也有很多 503 接近尾声（红色）

> status.find.in(200,304,201,202,203,204,205,206,207,208,209), b     78 (100.0%)
ut actually found 503

Gatling.conf 也设置为增加超时：

   timeOut {
      simulation = 8640000 # Absolute timeout, in seconds, of a simulation
    }
    ahc {
      #keepAlive = true                                # Allow pooling HTTP connections (keep-alive header automatically added)
      connectTimeout = 600000                          # Timeout when establishing a connection
      handshakeTimeout = 600000                        # Timeout when performing TLS hashshake
      pooledConnectionIdleTimeout = 600000             # Timeout when a connection stays unused in the pool
      readTimeout = 600000                             # Timeout when a used connection stays idle
      #maxRetry = 2                                    # Number of times that a request should be tried again
      requestTimeout = 600000

【问题讨论】：

ahc 在 http 块内吗？
是的，在 gatling.conf 的 http 块内 - core.timeout 和 http.ahc
检查这个属性：spring.mvc.async.request-timeout= #异步请求处理超时前的时间量。

标签： java spring spring-boot tomcat gatling

【解决方案1】：

根据 Rcordoval 的 cmets -

检查这个属性：spring.mvc.async.request-timeout= #Amount of 异步请求处理超时前的时间

此设置有助于其他 gatling 配置

spring.mvc.async.request-timeout=1200000

然而，根本原因是，当请求大量出现时，所有工作线程 (200) 都会在上传打开的连接 (2000) 时被占用（控制器将 MultipartFile 作为参数并返回 DeferredResult ）

我认为DeferredResult 在请求服务逻辑快而业务逻辑慢（在 forkjoin.commonPool 上运行）时会发光。它不太适合 MultiPartFile 上传（阻塞和缓慢）等等，因此当文件大小很大时，响应不会很快恢复（如上面的每秒响应图表所示，仅在几秒钟后响应开始恢复，因为打开连接是 2000 人，工人只有 200 人）。如果增加了工人，那么无论如何它都会削弱异步处理的优势。

在这种情况下，请求处理（上传和阻塞）很慢，业务逻辑很快。因此响应已准备就绪，但所有工作线程 (200) 都忙于服务越来越多的请求，以致响应无法恢复并因此超时。

可能有理由为 request serve 和 response resume 在使用 DeferredResult 的异步处理中设置单独的池？

【讨论】：