问题描述
如何增加超时时间，以便在处理响应之前，请求不会超时?
How can timeout be increased so that till response is processed, request does not timeout?
Spring Boot中的Tomcat设置:
Tomcat settings in Spring Boot:
server.tomcat.max-connections=2000
server.tomcat.max-threads=200
server.connection-timeout=1200000
每秒请求数在15秒内提高了constantUsersPerSec(20) during (15)至300，所有请求均已得到满足，如下面的加特林(蓝色)所示.
Request per second were raised constantUsersPerSec(20) during (15) to 300 during course of 15 seconds and all requests were served as can be seen in plot below from gatling(blue).
scn.inject(
constantUsersPerSec(20) during (15),
)
这是由于max-connections = 2000使用200工作线程处理了300个请求.
This is due to max-connections = 2000 which served 300 requests using 200 worker threads.
控制器是用Spring MVC编写的，它返回DeferredResult来执行异步请求处理，因此一旦响应被处理，它将恢复响应.
Controller is written in Spring MVC which returns DeferredResult which does asynchronous request processing and therefore will resume response once response is processed.
但是，即使server.connection-timeout设置为较高的数字1200000，也有很多503指向结尾(红色)
But even though server.connection-timeout is set to high number 1200000 there are lot of 503 towards end (red)
> status.find.in(200,304,201,202,203,204,205,206,207,208,209), b 78 (100.0%)
ut actually found 503
Gatling.conf也设置为增加超时时间:
Gatling.conf is also set for increased timeout:
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
推荐答案
根据 Rcordoval -
此设置可帮助完成其余的配线架配置
This setting helps with rest of gatling configurations
spring.mvc.async.request-timeout=1200000
但是，根本原因是，当请求数量很大时，所有工作线程(200)都会占用上载打开的连接(2000)(控制器将MultipartFile作为参数并返回DeferredResult)
The root cause however is that when requests come in large numbers, then all worker threads (200) get occupied in uploading open connections (2000) (the Controller is taking MultipartFile as argument and returning a DeferredResult )
我认为DeferredResult在请求服务逻辑快速而业务逻辑缓慢时运行(在forkjoin.commonPool上运行).它不太适合MultiPartFile上载(阻塞和缓慢)，并且在文件大小较大时不适合，因为从那以后响应就无法快速恢复(如在以上每秒响应图表中所示，仅在几秒钟后响应就开始恢复，因为打开了连接)是2000，而工人只有200).如果增加了工作人员，则无论如何都会减轻异步处理的优势.
I think DeferredResult shines when request serve logic is fast and business logic is slow (runs on forkjoin.commonPool). It does not quite fits with MultiPartFile uploads (blocking and slow) and more so when File sizes are big since then responses are not quickly resumed (as can be seen in above response per sec chart, only after few seconds responses start resuming since open connections are 2000 and workers only 200). If workers are increased, it then mitigates advantages of async processing anyway.
在这种情况下，请求处理(上传和阻止)很慢，而业务逻辑很快.因此响应已经准备就绪，但是所有工作线程(200)都忙于处理越来越多的请求，以至于响应没有恢复，结果超时了.
In this case, request processing (upload and blocking) was slow and business logic was fast. so responses were getting ready but all the worker threads (200) are so busy serving more and more requests that responses are not getting resumed and timing out as a result.
在使用DeferredResult进行异步处理时，可能需要为request serve和response resume提供单独的池?
Probably makes a case for having separate pool for request serve and response resume in async processing with DeferredResult ?
这篇关于在Spring Boot中增加Tomcat的连接超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！