关于springboot内置tomcat最大请求数配置的一些问题

前言

springboot内置了tomcat。那么一个springboot web应用,最大的请求链接数是多少呢?很早以前就知道这个是有个配置,需要的时候,百度一下即可。但,事实并非如此,有几个问题我想大多数人还真不知道。比如:

  • 为什么会有最大连接数和等待队列两个配置:要限制最大链接,用一个最大连接数限制即可,搞个等待队列有什么用呢?(我看网上有说,就像是餐厅有在餐厅里等待上菜的(最大链接数),也有在外坐小板凳排队的(等待队列),但,餐厅这么设计,可以说是由于实际场地等因素,那程序呢?它考虑的是什么?)
  • 有两个应用A、B,A调用B的一个接口,A在http请求方法的开始和结尾记录了时间,相减得到值是20s,B方法在controller方法的开头和结尾(或者AOP拦截)也记录了时间是10s,如果认为接口15s以内都是正常的,那么B就会认为自己的接口正常,A认为B的接口不正常。那么这差的10s问题出在哪里?

说明:

  1. 有些结论叙述不太准,但是这并不重要,理解所表达的意思即可,不要纠结一个答案;
  2. 有些配置的默认值,或者结论现象和网上其他说法不同,不必怀疑,可能大家都是对的,我们的环境不同罢了

正文

关于spirngboot内置tomcat的最大请求数,大体有如下四个配置:(后续配置中,如不特殊说明,都是按照这个参数值来进行验证)

properties 复制代码
#最少的工作线程数,默认大小是10
server.tomcat.threads.min-spare=1
#最多的工作线程数,默认大小是200
server.tomcat.threads.max=2
#最大连接数,默认大小是8192。表示Tomcat可以处理的最大请求数量,超过8192的请求就会被放入到等待队列。
server.tomcat.max-connections=2
#等待队列的长度,默认大小是100。
server.tomcat.accept-count=4

结论

先直接上结论,后续一一用代码来实际论证:

  1. 最小工作线程数server.tomcat.threads.min-spare是一个优化配置,应用启动就会创建相应数目的线程(不管有没有请求),这些线程是不会被销毁的,而server.tomcat.threads.max是在请求的任务数多的时候,会临时创建的线程,之后这些线程会被销毁;
  2. 最大可接受的请求数为:server.tomcat.max-connections + server.tomcat.accept-count,超过该数目会拒绝请求;
  3. 最多能同时工作的线程数是:server.tomcat.threads.max
  4. 如果配置server.tomcat.max-connections 小于server.tomcat.threads.max,那么实际中创建的任务线程数应该是:server.tomcat.max-connections
  5. 最大连接数中的请求没有处理完之前,是不会处理等待队列中的请求的;
  6. 假如把最大连接数和等待队列都看作容器:那么
    • 并非 是要等最大链接数中的链接,全部处理完 了,才会处理等待队列中的链接,而是最大链接容器中,有空位了,等待队列中就会有个链接进入最大链接容器,从而又可以接受一个新的链接了(debug源码发现:其实接受最大链接的池子是一个无限队列,但是通过server.tomcat.max-connections来控制这个最多能容纳的链接,当等于max-connections之后,新的链接就会进入等待队列,判断是否拒绝链接,是判断当前请求中,server.tomcat.accept-count的值是否大于等于配置值,如果是就拒绝链接)
    • 等待队列的存在是有意义的,特别是在异步请求

论证

这里我准备了一个接口,不考虑其他代码(如拦截器、过滤器之类的)的执行耗时,就认为这个接口的耗时时间为10s:

java 复制代码
@GetMapping("/test10")
public String test10() throws InterruptedException {
    log.info("当前线程test10:{}.", Thread.currentThread().getName());
    Thread.sleep(10000);
    return "test10s";
}

应用启动就会创建min-spare个线程

依次将server.tomcat.threads.min-spare设置为1、2、3,会发现项目启动后,就会创建对应多个数目的线程数(不要将该数值设置的大于server.tomcat.threads.max),当链接超过了这个最小的线程数之后,就会再创建线程,但是不会超过最大链接数,这些线程最终会被销毁(项目启动时创建的server.tomcat.threads.min-spare的线程却不会被销毁)

最大可接受请求数:server.tomcat.max-connections + server.tomcat.accept-count

现在配置的server.tomcat.max-connections + server.tomcat.accept-count 为7,那么发起7个请求,就应该有6个请求得到正常响应,一个请求被拒绝:

最多能同时工作的线程数是:server.tomcat.threads.max

同样,用上面的验证结果,看响应时间:

我配置的server.tomcat.threads.max为2,意味着同时有两个线程会执行请求。那么,接口耗时10s,每两个线程的响应时间是相同的,两两之间相差10秒。

想一下开头说的:A、B两应用接口调用有10s的时间对不上,也许有一种可能就是这里:从接口打印的时间来看,是10秒,但是实际的响应却是10s、20s、30s。

由此可见:有些项目所谓的接口响应时间的记录,其实仅仅是记录的业务代码的执行时间。对于请求方而言,并非接口的响应时间。知道这个,对于分析问题,又多了一种思路了。

如果配置server.tomcat.max-connections 小于server.tomcat.threads.max,那么实际中创建的任务线程数应该是:server.tomcat.max-connections

这种配置法,在实际中是不存在的,我想,应该不会有人这么干吧!!!

复制代码
server.tomcat.threads.min-spare=1
server.tomcat.threads.max=3
server.tomcat.max-connections=2
server.tomcat.accept-count=4

依然是7个请求并发,结果一个失败,6个成功,耗时30秒:

看这个图,时间依旧是两两一组,说明虽然允许最多创建3个任务线程,但是实际最大链接有2个,那么也认为只有两个任务要执行,而不会管等待队列中的任务。只有等最大链接池中的任务有执行完的了,才会让等待队列中的任务进来。

如果把server.tomcat.threads.min-spare设置为3,结果也是一样的。

最大连接数中的请求没有处理完之前,是不会处理等待队列中的请求的

这个结论是在其他地方看到的,当时一直不理解:假如最大链接数中有10个请求,等待有2个,那么必须要等到这10个请求全部完成了,才会处理等待队列的两个吗?其实,这句话的意思应该是,创建出的线程只会处理最大连接数中的请求,当有一个请求完了之后,才会让等待队列中的请求进来,然后然后又被任务线程处理。即便有空余的任务线程,也不会处理等待队列中的请求。在:

如果配置server.tomcat.max-connections 小于server.tomcat.threads.max,那么实际中创建的任务线程数应该是:server.tomcat.max-connections

已经论证了。

等待队列存在的作用

虽然之前也有说了,最大连接数中的请求没有处理完之前,是不会处理等待队列中的请求的 ,但这个作用意义不大,毕竟在实际中,不会有人配置工作线程数小于最大线程数。

所以,从以上现象中看,这个等待队列的意义不大(从我的测试结果看,这个确实没有啥意义,但是如果看源码,它还是有作用的,但我认为按照官方指导数来配置就可以了,理解它的作用比较抽象),除非------------使用异步请求

之前的接口,都是同步请求的:工作线程从最大链接容器中拿取一个人请求处理,处理完之后,再拿取下一个,它所针对的是最大链接,和等待队列没有关系,但等待队列看到最大链接中有空位了,就安排它的一个链接请求去补位,所以,从这里看它的存在意义不大。

但如果是异步请求中,这个等待队列就有意义了:如之前所说,工作线程只管最大请求链接中的请求。那么如果我允许项目的最大链接说是10,只有一个参数控制这个值的话,在异步线程中几乎可以认为会同时处理10个请求,但有了等待队列,则可以控制同时处理的请求数了。描述的不是很准确,直接看结果:增加一个异步请求接口和之前的同步请求逻辑一样,从客户端的角度看,这两个接口都是耗时10s:

复制代码
@GetMapping("/testCallAble")
public Callable<String> testCallAble(){
    return () -> {
        log.info("当前线程:{}.", Thread.currentThread().getName());
        Thread.sleep(10000);
        return "hello";
    };
}

使用如下配置参数,依次请求两个接口:7个并发请求:

复制代码
server.tomcat.threads.min-spare=1
server.tomcat.threads.max=2
server.tomcat.max-connections=4
server.tomcat.accept-count=2

异步请求结果:1个请求失败,总耗时20秒:有4个请求(server.tomcat.max-connections的值)是同一时间返回的:说明任务线程由于异步请求,它空闲出来之后会处理最大链接数中的其他请求,但是不会处理等待队列中的请求。如果没有等待队列,那么就会造成这个异步线程会一下处理6(server.tomcat.max-connections+server.tomcat.accept-count)个请求链接的业务方法,这个时候可能服务器没有足够的资源。

同步请求结果:1个请求失败,总耗时30秒:每两个请求的响应时间是相同的:

通过以上例子以及之前的例子,对于这个等待队列,应该有了个较为清晰且模糊的认识了吧。哈哈!!!

相关推荐
Asthenia041229 分钟前
Spring扩展点与工具类获取容器Bean-基于ApplicationContextAware实现非IOC容器中调用IOC的Bean
后端
bobz9651 小时前
ovs patch port 对比 veth pair
后端
Asthenia04121 小时前
Java受检异常与非受检异常分析
后端
uhakadotcom1 小时前
快速开始使用 n8n
后端·面试·github
JavaGuide1 小时前
公司来的新人用字符串存储日期,被组长怒怼了...
后端·mysql
bobz9651 小时前
qemu 网络使用基础
后端
Asthenia04122 小时前
面试攻略:如何应对 Spring 启动流程的层层追问
后端
Asthenia04122 小时前
Spring 启动流程:比喻表达
后端
Asthenia04122 小时前
Spring 启动流程分析-含时序图
后端
ONE_Gua3 小时前
chromium魔改——CDP(Chrome DevTools Protocol)检测01
前端·后端·爬虫