我有一个multithreadingC ++networking应用程序，它侦听UDP数据包作为input – 然后，这些数据通过应用程序跳跃/通过各种队列和线程处理，最后推出TCP套接字。
我所看到的是，如果input缓慢地说5秒，总的响应时间（从内到外）是缓慢的（比如说100ms），并且如果input快速地进来，例如20 /秒，则响应时间也很快（〜50ms）。 这个观察真的很奇怪。 而且在快速情况下也会缩短响应时间，因为第一个响应总是很慢。 只是为了确保 – 在缓慢和快速情况下，应用程序的工作量完全相同。
事情已经试图调查这一点 –
它是一个运行Linux 2.6内核的双至强处理器 – 禁用Turbo boost，确保处理器处于C0状态。
消除networking原因。 根本原因是在框内。 （在软件或硬件中）
我有一个假input通过系统从input到输出定时器，以保持应用程序“温暖” – 没有效果。 （应用程序的工作线程正忙于等待并固定到内核）。
性能指标表明，每件事情都变慢了 – 这基本上意味着处理器在不连续负载的情况下正在减速 – 但没有其他任何迹象表明（17z / turbostat）或我正在读取它们不正确。
有人可能会发生什么颜色？
根据我的经验，这将是Nagle恶魔装置的恶劣行为。 听起来对我来说极其合理的是，缓冲区中的更多数据填满了比发送的TCP数据包。 没有太多的数据，TCP数据包正在等待对方的反应，这是我们都知道的延迟。
解决方法 – 学习确保在创建任何可发送TCP套接字后，首先将Nagle的程序杀手禁用。