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

发布于:2024-04-28 ⋅ 阅读:(46) ⋅ 点赞:(0)

前言

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

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

说明:

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

正文

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

#最少的工作线程数,默认大小是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:

@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的线程却不会被销毁)

image.png

image.png

image.png

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

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

image.png

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

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

image.png

我配置的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秒:

image.png

看这个图,时间依旧是两两一组,说明虽然允许最多创建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)个请求链接的业务方法,这个时候可能服务器没有足够的资源。
image.png

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

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


网站公告

今日签到

点亮在社区的每一天
去签到