iframe 拒绝了我们的连接请求_Spring Boot中内置Tomcat最大连接数、线程数与等待数的最佳实践...

在 Spring Boot框架中,我们使用最多的是Tomcat,这是Spring Boot默认的容器技术,而且是内嵌式的 Tomcat。

Tomcat 是 Apache 基金下的一个轻量级的Servlet容器,支持Servlet和JSP。Tomcat服务器本身具有Web服务器的功能,可以作为独立的Web服务器来使用。

一、Spring Boot应用中Tomcat建议配置

Spring Boot 能支持的最大并发量主要看其对Tomcat的设置,可以在配置文件中对其进行更改。

要了解具体参数的默认值,一个简单的方法是在application.properties 配置文件中输入配置项, 默认值就会显示出来。

##最大工作线程数,默认200。(4核8G内存, 线程数经验值800,操作系统做线程之间的切换调度是有系统开销的,所以不是越多越好。)

server. tomcat.max-threads=200

##最大连接数默认是10000

server.tomcat.max-connections=10000

## 等待队列长度,默认100。

server.tomcat.accept-count=100

##最小工作空闲线程数,默认10。(可以适当增大一些,以便应对突然增长的访问量)

server. tomcat.min-spare-threads=100

对应application.yml 配置文件如下所示:

server:

tomcat:

accept-count:100

max-connections:10000#最大可被连接数,默认为10000

max-threads:200#最大工作线程数

min-spare-threads:10#最小工作线程数

4核8G内存单进程调度线程数800-1000,超过这个并发数之后,将会花费巨大的时间在CPU调度上。

等待队列长度:队列做缓冲池用,但也不能无限长,消耗内存,出入队列也耗CPU。

线程数的经验值为:1核2G内存,线程数经验值200;4核8G内存,线程数经验值800。

maxThreads规定的是最大的线程数目,并不是实际running的CPU数量;实际上,maxThreads 的大小比CPU核心数量要大得多。这是因为,处理请求的线程真正用于计算的时间可能很少,大多数时间可能在阻塞,如等待数据库返回数据、等待硬盘读写数据等。因此,在某一时刻,只有少数的线程真正的在使用物理CPU,大多数线程都在等待;因此线程数远大于物理核心数才是合理的。也就是说,Tomcat通过使用比CPU核心数量多得多的线程数,可以使CPU忙碌起来,大大提高CPU的利用率。

针对4C 8G配置,可以参考建议值:

server:

tomcat:

accept-count:1000

max-connections:1000

max-threads:800

min-spare-threads:100

Spring Boot的默认配置信息,都在 spring-boot-autoconfigure版本号jar 这个包中。其中上述

Tomcat的配置在/web/ServerProperties.java 中。

二、最 大 并 发 量-maxThreads 和maxConnections参数

比 较 容 易 弄 混的 是 maxThreads 和maxConnections这两个参数:

maxThreads是指Tomcat线程池最多能起的线程数,而maxConnections则是Tomcat一瞬间最多能够处理的并发连接数。

比如maxThreads=1000 maxConnections=800,假设某一瞬间的并发是1000,那么最终Tomcat的线程数将会是800, 即同时处理800个请求,剩余200 进 入 队 列"排 队",如 果acceptCount=100(100个请求进入排队),另外100个请求会被拒掉。

并发量指的是连接数,还是线程数?

当然是连接数(maxConnections)。

200个线程如何处理1000条连接?

Tomcat有两种处理连接的模式,一种是BIO,一个线程只处理一个Socket连接;另一种就是

NIO,一个线程处理多个Socket连接。由于HTTP请求不会太耗时,而且多个连接一般不会同时来消息,所以一个线程处理多个连接没有太大问题。

Tomcat的最大连接数参数是maxConnections, 这个值表示最多可以有多少个Socket连接到Tomcat上。BIO模式下默认最大连接数是它的最大线程数(缺省是200),NIO模式下默认是10000,APR模式则是8192。

为什么不开更多线程?

多开线程的代价就是,增加上下文切换的时间, 浪费CPU时间。另外还有就是线程数增多,每个线程分配到的时间片就变少。多开线程并不等于提高处理效率。

那增加最大连接数(maxConnections)呢?

增加最大连接数,支持的并发量确实可以上去。但是在没有改变硬件条件的情况下,这种并发量的提升必定以牺牲响应时间为代价。

三、maxConnections和acceptCount参数

maxConnections和acceptCount的关系为:当连接数达到最大值maxConnections后,系统会继续 接 收 连接,进行 排队,但不会 超过acceptCount的值。

Tomcat最大连接数取决于maxConnections这个值加上acceptCount这个值,在连接数达到了maxConenctions之后,Tomcat仍会保持住连接,但是不处理,等待其它请求处理完毕之后才会处理这个请求。

当队列(acceptCount)已满时,任何的连接请求都将被拒绝。acceptCount的默认值为100。

简而言之,当调用HTTP请求数达到Tomcat的最大连接数时,还有新的HTTP请求到来,这时Tomcat会将该请求放在等待队列中,这个acceptCount就是指能够接受的最大等待数,默认100。如果等待队列也被放满了,这个时候再来新的请求就会被Tomcat拒绝(connection refused)。

下面就是前端发起请求数,超出acceptCount最大等待数,无法建立连接(ECONNRESET,

Connection was reset)。

四、图解maxConnections、maxThreads、acceptCount关系

maxConnections、maxThreads、acceptCount 关系图如下:

4ee60e3a9737da30028a0a3f45998c7a.png

用一个形象的比喻,通俗易懂的解释一下Tomcat的最大线程数(maxThreads)、最大等待 数(acceptCount)和 最 大 连 接 数(maxConnections)三者之间的关系。

我们可以把Tomcat比做一个火锅店,流程是取号、入座、叫服务员,可以做一下三个形象的类比:

(1)acceptCount最大等待数

可以类比为火锅店的排号处能够容纳排号的最大数量;排号的数量不是无限制的,火锅店的排号到了一定数据量之后,服务往往会说:已经客满。

(2)maxConnections 最大连接数

可以类比为火锅店的大堂的餐桌数量,也就是可以就餐的桌数。如果所有的桌子都已经坐满,则表示餐厅已满,已经达到了服务的数量上线,不能再有顾客进入餐厅了。

(3)maxThreads:最大线程数

可以类比为厨师的个数。每一个厨师,在同一时刻,只能给一张餐桌炒菜,就像极了JVM中的一条线程。

整个就餐的流程,大致如下:

(1)取号:如果maxConnections连接数没有满,就不需要取号,因为还有空余的餐桌,直接被大堂服务员领上餐桌,点菜就餐即可。如果maxConnections连接数满了,但是取号人数没有达到acceptCount,则取号成功。如果取号人数已达到acceptCount,则拿号失败,会得到Tomcat的Connection refused connect 的回复信息。

(2)上桌:如果有餐桌空出来了,表示maxConnections连接数没有满,排队的人,可以进入大堂上桌就餐。

(3)就餐:就餐需要厨师炒菜。厨师的数量, 比顾客的数量,肯定会少一些。一个厨师一定需要给多张餐桌炒菜,如果就餐的人越多,厨师也会忙不过来。这时候就可以增加厨师,一增加到上限maxThreads的值,如果还是不够,只能是拖慢每一张餐桌的上菜速度,这种情况,就是大家常见的"上一道菜吃光了,下一道菜还没有上"尴尬场景。

五、connectionTimeout超时设置

这个参数容易混淆,先看看官方的解释:

Time that connectors wait for another HTTP request before closing the connection.

When not set, the connector's container-specific default is used. Use a value of -1 to indicate no(that is,an infinite)timeout.

connectionTimeout是连接器在关闭连接之前, 等待下一个HTTP请求的时间。注意:不是请求超时的时间,请求超时时间需要在Client端设置。

如果没有设置,则使用连接器对应特定容器(Tomcat)的默认值。如果设置为-1,表示没有超时设置,也就是无限时间。

Tomcat容器中connectionTimeout 以毫秒为单位,默认设置为20秒。

简单来说,connectionTimeout是本条连接(connector)等多久没数据发送过来,就关闭连接。这样,可以避免连接数被占满。

已标记关键词 清除标记
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 1024 设计师:白松林 返回首页