Netty文件传输代理在高并发性下遭受大连接延迟

Question

我正在做一个使用netty构建文件传输代理的项目,它应该有效地处理高并发性.

这是我的结构:

Back Server,一个普通的文件服务器,就像netty.io上的Http(文件服务器)示例一样,它接收并确认请求并使用ChunkedBuffer或零拷贝发送文件.

具有NioServerSocketChannelFactory和NioClientSocketChannelFactory的代理都使用cachedThreadPool,侦听客户端的请求并将文件从Back Server提取回客户端.接受新客户端后,NioServerSocketChannelFactory创建的新接受的Channel(channel1)将等待请求.收到请求后,代理将使用NioClientSocketChannelFactory与Back Server建立新连接,新的Channel(channel2)将向Back Server发送请求并将响应传递给客户端.每个channel1和channel2使用自己的管道.

更简单的说,程序是

1. channel1被接受了

2. channel1接收请求

3. channel2连接到Back Server

4. channel2向Back Server发送请求

5. channel2从后台服务器接收响应(包括文件)

6. channel1将从channel2获得的响应发送给客户端

7. 传输完成后,channel2关闭,channel1关闭刷新(每个客户端只发送一个请求)

由于所需文件可能很大(10M),因此当channel1不可写时,代理会停止channel2.readable,就像netty.io上的示例代理服务器一样.

利用上述结构,每个客户端具有一个接受的信道,并且一旦它发送请求,它也对应于一个客户端信道,直到完成传输.

然后我使用ab(apache bench)向代理发出数千个请求并评估请求时间.代理,后台服务器和客户端是一个机架上的三个盒子,没有其他流量加载.

结果很奇怪:

1. 文件大小10MB,当并发性为1时,连接延迟非常小,但当并发性从1增加到10时,最高1%的连接延迟变得非常高,最多3秒.其他99%非常小.当并发性增加到20时,1%会增加到8秒.如果并发性高于100,它甚至会导致ab超时.90%处理延迟通常与并发性成线性关系,但1%可以在随机并发数下异常地变得非常高(在多次测试中变化).

2. 文件大小1K,一切都很好,并发性低于100.

3. 将它们放在一台本地机器上,没有连接延迟.

任何人都可以解释这个问题并告诉我哪个部分是错的？我在网上看到很多基准测试,但它们是纯粹的乒乓测试,而不是这个大文件传输和代理的东西.希望这对你们感兴趣:)

谢谢!

================================================== ======================================

在今天阅读了一些源代码之后,我发现一个地方可能会阻止接受新的套接字.在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帮助.