在连接请求和性能问题之间传播等待时间

Question

我开发了一个基于带Netty的tcp/ip-stack自定义协议的服务器。写这个很愉快。

现在我正在测试性能。我在netty上编写了一个测试应用程序，它只需连接大量（20.000+）“客户端”到服务器（在每次引导连接后使用Thread.wait（1）for循环）。一旦连接了一个客户端通道，它就会向服务器发送一个登录请求，该请求会检查该帐户并发送登录响应。

整体表现似乎相当不错。所有客户都在60秒以内登录。但不好的是每个连接的等待时间。我有非常快速的登录和极慢的登录。在整个测试时间内，变化范围从9ms到40,000ms。是否有可能在请求的频道（Fifo）之间共享等待时间？

我测量了很多重要的时间戳，发现了一个奇怪的现象。我有很多连接，其中服务器的“通道连接”时间戳在客户端的时间戳之后（最长为19秒）。我也有“正常”的情况，他们匹配，只是客户端发送和服务器接收之间的时间是几秒钟。在这两种情况之间都有一些情况。怎么可能，客户端和服务器“通道连接”是相距太远的时间？

可以肯定的是，客户端立即在发送后立即收到服务器的登录响应。

调整： 我想我读了大部分表现文章在这里。我在4CPU-Hyper-Threading-i7上使用带有200个线程的OrderMemoryAwareThreadPool作为传入连接，并且还使用已知的激进选项启动服务器应用程序。我也完全调整了我的Win7-TCP-Stack。 服务器在我的机器上运行非常流畅。 CPU使用率和内存消耗是ca.在50％以上可以使用。

太多的信息： 我还从2个独立的机器中启动了2个测试应用程序，每个机器以15000个连接“并行攻击”服务器。在那里，我有大约800个连接从服务器获得超时。这里有什么意见？

最好的问候和欢呼声给了Netty， 马丁

Answer 1

的Netty有一个专门的老板线程接受传入连接。如果boss线程接受新的连接，它将连接转发给工作线程。由于这个原因，接受和实际套接字读取之间的等待时间可能会大于预期负载。虽然我们正在研究改善情况的不同方法，但同时，您可能希望增加工作线程数，以便工作线程处理更少的连接数。

如果您认为它的表现比非Netty应用程序差，请随时与file an issue一起复制测试用例。我们将尝试重现并解决问题。