我开发了一个基于tcp / ip-stack和Netty的自定义协议服务器。写这个是一种乐趣。
现在我正在测试性能。我在netty上编写了一个测试应用程序，它只是将许多（20.000+）“客户端”连接到服务器（在每次bootstrap-connect之后使用Thread.wait（1）进行for循环）。一旦连接了客户端通道，它就会向服务器发送登录请求，该请求会检查帐户并发送登录响应。
整体表现似乎相当不错。所有客户都在60岁以下登录。但是，每个连接的传播等待时间并不是那么好。我有非常快的登录和极慢的登录。在整个测试时间内，从9ms到40.000ms的变化范围。是否有可能在请求频道（Fifo）之间共享等待时间？
我测量了很多重要的时间戳，发现了一个奇怪的现象。我有很多连接，服务器的“频道连接”的时间戳是在客户端的时间戳之后（最多19秒）。我也有“正常”的情况，它们匹配，只是客户端发送和服务器接收之间的时间是几秒钟。在这两种情况之间存在着所有情况。怎么可能，客户端和服务器“通道连接”的时间相隔很远？
可以肯定的是，客户端在发送后立即收到服务器的登录响应。
调整： 我想我在这里阅读了大部分的性能文章。我在4CPU-Hyper-Threading-i7上使用带有200个线程的OrderMemoryAwareThreadPool作为传入连接，并且还使用已知的aggressive-options启动服务器应用程序。我也完全调整了我的Win7-TCP-Stack。 服务器在我的机器上运行非常顺畅。 CPU使用率和内存消耗大约是从可以使用的50％开始。
信息过多： 我还从两台独立的机器开始了我的两个测试应用程序“并行攻击”服务器，每个机器有15.000个连接。我有大约800个连接从服务器超时。这里有什么意见吗？
对Netty致以最诚挚的问候和欢呼， 马丁
答案 0 :(得分：2)
Netty有一个专用的boss线程，可以接受传入的连接。如果boss线程接受新连接，它会将连接转发给工作线程。由于这个原因，接受和实际套接字读取之间的延迟可能比负载下的预期更大。虽然我们正在研究改善这种情况的不同方法，但是，您可能希望增加工作线程的数量，以便工作线程处理更少数量的连接。
如果您认为它的表现比非Netty应用程序更差，请随时使用复制测试用例file an issue。我们将尝试重现并解决问题。