Tomcat 和 acceptCount 不工作

Question

我正在使用 tomcat 8 作为 Spring Boot 项目的一部分，我的 acceptCount 设置似乎不起作用。我的服务器接受了将近 1000 个连接，而不是只接受 300 个连接，当然同时处理的连接不超过 200 个。

Tomcat 文档在 acceptCount 上似乎很清楚:“当所有可能的请求处理线程都在使用中时，传入连接请求的最大队列长度。当队列已满时收到的任何请求都将被拒绝。”但显然这不会发生。

当然还有另一个设置，maxConnections，它的文档说:“请注意，一旦达到限制，操作系统可能仍会根据 acceptCount 设置接受连接”——但仅此注释并不意味着 acceptCount是“依靠 maxConnections，而不是 maxThreads”(就像 https://coderanch.com/t/647733/application-servers/Tomcat-BIO-connector-configurations 的 topicstarter 认为的那样)。这只是意味着它在两种情况下都会产生影响:当所有处理线程都忙时，以及当所有可用连接都耗尽时。 (即使那个人是正确的，那也意味着 Tomcat 文档在定义 acceptCount 时是完全错误的...)

那为什么会被忽略呢？我发现一些讨论提到人们声称 acceptCount 对他们不起作用，但没有找到实际的讨论 :( 即使相反，我也能找到一些关于 Tomcat 在 300 个连接后如何阻塞的提示(这完全是默认的maxThreads + acceptCount)。所以我可以看到对于某些人来说它有效，并且我被要求相信“也许”对于某些人来说它没有。对我来说也不是。我应该相信 Tomcat 手册在某种意义上是错误的这个选项并不总是被尊重？

Answer 1

所有这些设置之间存在复杂的关系，并且由于您选择的连接器(例如 BIO、NIO、APR 等)而使它们变得更加复杂。

BIO 连接器基本上已失效...它在 Tomcat 8.0.x 之后不存在。它不能接受超过线程池一次可以处理的连接数。因此，BIO 连接器本质上使 maxConnections == maxThreads。因此，对于一个BIO连接器，服务器愿意接受的连接数应该是maxConnections + acceptCount，但是maxConnections是有限制的数量相对较少。

在 TCP/IP 意义上，其他更复杂的连接器允许每个线程接受多个连接。maxConnections 的默认值更接近于10k(因具体类型而异)，与线程池大小无关，因此服务器愿意接受的连接数为 maxConnections + acceptCount。

非 BIO 连接器可以接受更多连接的原因是因为这两种状态不需要事件的请求处理线程(等待下一个 HTTP-keepalive-request - 使用 read() 和等待下一个连接 - 使用 accept()) 由一个单独的线程完成，允许请求处理线程尽快返回池中以便为其他线程提供服务请求。

如果您使用的是 BIO，我预计连接会在例如300 个连接(你没有发布你的配置，所以不可能说出实际数字是多少)但对于 NIO，我预计它会超过 10k 个连接。

对于测试，重要的是您实际上不对您的连接做任何事情以正确计算它们。基本上，您需要这样做:

foreach(i from 0..10301)
    conn[i] = connect('host:port')

您应该会发现服务器不会接受某些i 的连接。如果您连接并发出 GET/，则服务器将响应并且连接和请求处理线程将返回到它们各自的池中。

** 阅读一些评论后更新**

我希望能够同时处理 200 个请求，但 Tomcat 会很乐意在内部排队另外 800 个请求。 acceptQueue 中的额外 200 个正在由操作系统的 TCP/IP 堆栈排队，而不是由 Tomcat/Java

假设客户端无限读取超时，我希望您能够启动 1201 个 curl 实例，其中门内的前 200 个实例立即获得一个线程(并休眠)，接下来的 800 个在 Tomcat/Java 中排队，接下来的 200 个在 TCP/IP 堆栈中排队，实例 #1201 得到“连接被拒绝”响应。

一旦完成第一组 200 个请求，Tomcat 将处理另一批 200 个请求，TCP/IP 队列中的 200 个连接将从该队列移动到 Tomcat/Java 队列，20 秒后第二组将完成 200 个请求。这将重复，直到所有 1200 个初始请求都向其客户返回响应。 1200 个请求中只有 1 个会被拒绝。