connectionTimeout 指定超时的时间数( 以毫秒为单位)
详细可见http://blog.csdn.net/yuanxuegui2008/article/details/6056754
首先,先理解两个概念:连接超时和数据超时1、连接超时,就是在规定时间内还没有建立连接,就抛出连接超时异常
2、数据超时,就是在规定时间内还没有读到数据,就抛出读数据超时异常
其次,连接超时和数据超时都是分别设置超时时间的,因此不存在设置10s,连接用5s,读数据5s的说法
也就是说,你可以设置超时时间30s,读取数据超时时间30s,两个时间不会互相干预,分别设置。
因此,你需要搞清楚tomcat设置的超时时间是指连接超时还是读取数据超时。
最后建议,先搞清楚TCP/IP协议,因为tomcat内部最终是围绕原始的TCP/IP协议封装的。
如果TCP、HTTP协议都搞懂了,你不会被tomcat、httpclient等这样的第三方应用搞糊涂!
Tomcat 作为 Java Web 程序比较常用的 Servlet 容器实现,在 Web 开发中有比较重要的地位。
Tomcat 有三种 IO 模式,BIO、NIO、APR。
在 Tomcat7 及以下 Linux 中默认启用的是 BIO 模式,Tomcat8 及以上使用的是 NIO 模式,利用 Java 的异步 IO 处理,可以通过少量的线程处理大量的连接请求。
除这两种方式外,还有一种 APR(Apache Portable Runtime) 模式,从 *** 作系统层面解决 IO 阻塞问题。Tomcat7 或Tomcat8 在 Win7 或以上的系统中启动默认使用这种方式。
要注意的是,在 SpringBoot 内嵌的 Tomcat 不自动开启 APR 模式,需要手动进行配置。
可以通过启动日志看到 SpringBoot 中启用的 IO 模式:
关于 BIO、NIO、APR 的详解不做过多介绍。
这个参数是指在同一时间,Tomcat 能够接受的最大连接数。对于 Java 的阻塞式 BIO,默认值是 maxthreads 的值;可以通过配置 Executor 执行器来修改这个值。
对于 Java 新的 NIO 模式,maxConnections 默认值是 10000。
对于 windows 上 APR/native IO模式,maxConnections 默认值为 8192,这是出于性能原因,如果配置的值不是 1024 的倍数,maxConnections 的实际值将减少到 1024 的最大倍数。
如果设置为 -1,则禁用 maxconnections 功能,表示不限制tomcat容器的连接数。
简单来说就是 Tomcat 总共允许建立多少连接。
每一次 Http 请求到达 Web 服务,Tomcat 都会创建一个线程来处理该请求,最大线程数决定了 Web 服务同时可以处理多少请求。maxThreads 默认值为 200,建议增加,但是增加线程是有成本的,更多的线程代表会有更多的上下文切换,也意味着 JVM 会分配更多的内存。
当 Tomcat 的最大连接数 maxConnections 被占满之后,后续的请求就会进行排队,排队的最大数量就是 acceptCount,举个例子,当前 maxConnections 为 10,acceptCount 为 5,并且 maxConnections 已经使用了 10,那么后续的请求就会排队,每来一个请求,acceptCount 就会 +1 ,当 acceptCount 增加到 5 ,在后续的请求就会被直接放弃。
HTTP 协议运行在 TCP 之上,所以每次请求到来,客户端和服务端会建立一次 TCP 连接,建立连接需要三次握手,所以就需要一定的时间,connection-timeout 限制了连接建立的时间,当建立连接时间超过这个值,连接就会建立失败。默认为 20000ms。
常用配置:
我们可以把 Tomcat 比作餐厅,餐厅有排队取号区域,餐桌,厨房,厨师。
maxConnections 可以类比为餐桌数量,acceptCount 可以类比为排队取号队列长度,maxThreads 可以类比为厨房里厨师的数量。
当客人来的时候,如果餐桌数量没坐满,客人可以直接上餐桌点餐,点餐之后,厨师就会做这一桌的食物,一个厨师同时只能为一桌服务。
当客人来的时候,如果餐桌坐满了,就需要去排队取号区排队取号,如果取号区人也排满了,餐厅就会赶你走。
由于厨师数量可能少于餐桌的数量,所以会出现多个厨师负责多个餐桌的情乱,也就是线程数量不够,连接等待处理的情况。
SpringBoot 配置:
接口定义(模拟处理需要 5 秒):
使用 Jmeter 同时使用 50 个线程访问测试:
查看测试报告:
测试结果:
只有两个请求请求成功,因为最大连接数为1 ,排队数量为 1,所以最多只能处理两个请求,其余的 48 个请求直接被丢弃。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)