应用程序的响应时间与给定时间段内输入触发器的数量不经意地相关

Response time of an application unintutively correlated with number of input triggers in a give time period

本文关键字：不经意 触发器 响应时间 定时间 应用程序 时间段 输入      更新时间：2023-10-16

我有一个多线程C++网络应用程序，它侦听UDP数据包作为输入-然后这些数据在应用程序中跳跃/通过各种队列和线程进行处理，最后在TCP套接字上推出。

我看到的是，如果输入速度很慢，比如说5/sec，总响应时间（从内到外）很慢（比如说100ms），如果输入很快，比如20/sec，响应时间也很快（~50ms）。这种观察真的很奇怪。在快速情况下也会打乱响应时间，因为第一次响应总是很慢。只是为了确保应用程序在慢速和快速情况下都能完成完全相同的工作量。

已经尝试调查的事情-

  • 它是一个运行Linux 2.6内核的双Xeon机箱，禁用Turbo boost，确保处理器处于C0状态。

  • 消除了网络原因。根本原因就在盒子里。（软件或硬件）

  • 我在计时器上有一个从输入到输出的假输入通过系统，以保持应用程序"温暖"——没有效果。（申请的工作线程正忙于等待并固定到核心）。

  • perf点表明，每件事都会变慢——这基本上意味着处理器在没有持续负载的情况下会变慢，但没有其他迹象表明（17z/turbostat）或我读错了。

有人知道可能发生的事情吗？

根据我的经验，这将是Nagle魔鬼装置的恶劣行为。对我来说，缓冲区中填充TCP数据包的数据比发送的要多，这听起来非常合理。在没有太多数据的情况下，tcp数据包正在等待来自另一端的ack，众所周知，这是延迟的。

解决方案-在创建任何可发送的TCP套接字后，首先要确保禁用Nagle的程序杀手。

相关文章：