我正在编写一个 Netty 应用程序。该应用程序在 64 位八核 linux 机器上运行
Netty 应用程序是一个简单的路由器,它接受请求(传入管道)从请求中读取一些元数据并将数据转发到远程服务(传出管道)。
此远程服务将向传出管道返回一个或多个响应。Netty 应用程序会将响应路由回原始客户端(传入管道)
将有成千上万的客户。将有数千个远程服务。
我正在做一些小规模的测试(十个客户端,十个远程服务),我没有看到我期望的 99.9% 的 10 毫秒以下的性能。我正在从客户端和服务器端测量延迟。
我正在使用类似于 SPDY 的完全异步协议。我在处理 FrameDecoder 中的第一个字节时捕获时间(我只使用 System.nanoTime())。我在调用 channel.write() 之前停止了计时器。我正在测量从传入管道到传出管道的亚毫秒时间(99.9%),反之亦然。
我还测量了从 FrameDecoder 中的第一个字节到在(以上)message.write() 上调用 ChannelFutureListener 回调的时间。时间高达几十毫秒(99.9%),但我很难说服自己这是有用的数据。
我最初的想法是我们有一些缓慢的客户。我观看了 channel.isWritable() 并在返回 false 时记录。这个方法在正常情况下没有返回false
一些事实:
- 我们正在使用 NIO 工厂。我们没有自定义工人大小
- 我们已禁用 Nagel (tcpNoDelay=true)
- 我们启用了保持活动 (keepAlive=true)
- CPU 90+% 的时间处于空闲状态
- 网络空闲
- GC(CMS)每 100 秒左右被调用一次,时间很短
有没有我可以遵循的调试技术来确定为什么我的 Netty 应用程序没有像我认为的那样快速运行?
感觉就像 channel.write() 将消息添加到队列中,而我们(使用 Netty 的应用程序开发人员)对此队列没有透明度。我不知道队列是Netty队列,OS队列,网卡队列还是什么。无论如何,我正在审查现有应用程序的示例,但我没有看到我正在遵循的任何反模式
感谢您的帮助/见解