具有异步servlet工作和可伸缩性的Tomcat连接器

Question

简而言之，我是这样理解的：

null

我有以下问题:
1)如果我不在Tomcat上使用TSL，那么在NIO之前使用ARP有什么优势吗？我在热身后测试我的应用程序，我注意到ARP处理请求比NIO慢，在处理请求时偶尔会暂停。JIT>本机代码？或者在某些条件下它可以运行得更快？
2)如果NIO2使用hadnler回调，这是否意味着我需要分配更多的线程？
3)NIO2比nio快？因为第一次查看时，NIO线程被迫显式轮询通道，而在NIO2的情况下是由操作系统启动的，而不是应用程序本身。我的测试证实了这一点，但每个情况都是个别的，所以我想知道详细情况。
4)所有连接器都有sendfile功能。根据上面的资源“选择tomcat连接器”，NIO2模拟了这一点。这是什么意思？如果我使用Nginx来服务静态文件，这个功能有意义吗？

对我来说，最大的惊喜是所有的连接器仍然在使用阻塞操作。官方文件证实了这一点。读请求正文和写响应头和正文是阻塞操作。关于这一点，我想在下面谈谈。

接下来，我想了解所有的线程在真正的应用程序中是如何工作的。例如，我有一个4核CPU，我选择NIO connector决定设置这样的参数:maxthread=“4”和maxConnection=“1000”

之后，我启动了VisualVM。以下是我感兴趣的线程:
http-nio-8080-exec[1-4]、http-nio-8080-clientpooler-[0-1]和nioblockingselector.blockpoller

据我所知，ClientPollers管理读取请求行的非阻塞选择器，并等待keep-alive请求。BlockPoller模拟请求正文读/响应写的阻塞。但是为什么要使用阻塞操作呢？这是否与“慢速客户端不会使线程停滞”这一结论相矛盾？
在酝酿了这么多问题之后:
5)exec线程只处理我的请求，或者它们还执行从通道/到通道的读/写操作？我回答这个问题，因为您可以想象一下，如果我们有10个传入请求，但只有4个线程可以处理请求。

我有以下假设:
a)同时，servlet处理4个请求，但仍然可以从其余6个请求的套接字中读取数据（请求头、正文）（因为我们在另一个线程中有工作池）。当前4个请求完成时，其余6个将已经读取所有数据，并且可以立即处理（按照队列的顺序）。因此，I/O不会空闲工作。（但没有解决在NioBlockingSelector中阻塞操作的问题）
b)Servlet处理4个请求，但我们不能从网络缓冲区中读取其他6个请求的数据，只能建立连接。原来exec线程也执行任何读取操作，所以这些线程在处理Servlet中的“用户代码”时被阻塞。在这种情况下，我考虑异步Servlet。我确定了线程池的大小为10。现在控制器中的长查询可以如下定义：

@GetMapping
public Callable<String> longRunningRequest(){
    return () -> {
        // long method
        return "someView";
    };
}

因此，现在执行线程总是准备好读/写数据。但是，如果我只是在连接器配置中定义MaxThreads=4+10，会有什么不同呢？在异步servlet的情况下，似乎我们只是将一个线程交换到另一个线程。或者，如果对于短请求使用exec线程，而对于长运行的请求使用带有专用线程池的异步servlet，这可能会有好处？

Answer 1

不可以。如果您有一个为静态文件服务的反向代理，那么将这些请求代理到Tomcat，然后使用sendfile（模拟或不模拟）将数据返回给客户机只会降低性能。

对我来说，最大的惊喜是所有的连接器仍然在使用阻塞操作。

你为什么要惊讶？servlet API构建在阻塞API的基础上（例如java.io.InputStream、java.io.outputStream等）。如果您想要非阻塞行为，您将希望使用WebSocket。