我正在做一个使用netty构建文件传输代理的项目，它应该有效地处理高并发性。
这是我的结构：
Back Server ，一个普通的文件服务器，就像netty.io上的Http（文件服务器）示例一样，接收并确认请求并使用ChunkedBuffer或零拷贝发送文件。
代理，同时使用NioServerSocketChannelFactory和NioClientSocketChannelFactory，都使用cachedThreadPool，侦听客户端请求并将文件从 Back Server 提取回客户端。接受新客户端后，NioServerSocketChannelFactory创建的新接受的Channel（channel1）将等待请求。收到请求后，代理将使用NioClientSocketChannelFactory建立与 Back Server 的新连接，新的Channel（channel2）将向Back Server发送请求并发送响应给客户。每个channel1和channel2使用自己的管道。
更简单的说，程序是
channel1已接受
channel1收到请求
channel2连接到Back Server
channel2向Back Server发送请求
channel2从后台服务器接收响应（包括文件）
channel1将从channel2获取的响应发送到客户端
传输完成后，channel2关闭，关闭时channel1关闭。（每个客户端只发送一个请求）
由于所需文件可能很大（10M），因此当channel1不可写时，代理会停止channel2.readable，就像netty.io上的示例代理服务器一样。
使用上述结构，每个客户端都有一个接受的频道，一旦发送请求，它也会对应一个客户端频道，直到完成传输。
然后我使用ab（apache bench）向代理发出数千个请求并评估请求时间。代理，后台服务器和客户端是一个机架上的三个盒子，没有其他流量加载。
结果很奇怪：
文件大小10MB，当并发为1时，连接延迟非常小，但当并发从1增加到10时，前1％的连接延迟变得非常高，直到 3秒其他99％非常小。当并发性增加到20时，1％会增加到8秒。如果并发性高于100，它甚至会导致ab超时.90％处理延迟通常与并发性成线性关系，但1％可以在随机并发数下异常地变得非常高（在多次测试中变化）。
文件大小1K，一切都很好，并发性低于100。
将它们放在一台本地计算机上，没有连接延迟。
任何人都可以解释这个问题并告诉我哪个部分是错的？我在网上看到很多基准测试，但它们是纯粹的乒乓测试，而不是这个大文件传输和代理的东西。希望这对你们感兴趣:)
谢谢！
=============================================== =========================================
在今天阅读了一些源代码后，我发现一个地方可能会阻止接受新的套接字。在NioServerSocketChannelSink.bind（）中，boss执行器将调用Boss.run（），其中包含一个用于接受传入套接字的for循环。在此循环的每次迭代中，在获取接受的通道之后，将调用AbstractNioWorker.register（），它假定将新套接字添加到在worker executor中运行的选择器中。但是，在 register（），在调用worker executor之前必须检查一个名为startStopLock的互斥锁。此startStopLock也用于AbstractNioWorker.run（）和AbstractNioWorker.executeInIoThread（），它们都会在调用工作线程之前检查互斥锁。换句话说，startStopLock用于3个函数。如果它在AbstractNioWorker.register（）中被锁定，Boss.run（）中的for循环将被阻止，这可能导致传入的接受延迟。希望这位ganna帮助。