c - UDP sendto 环回性能

Question

背景

我有一个非常高吞吐量/低延迟的网络应用程序(目标是每个数据包 << 5 usec)，我想向它添加一些监控/指标。我听说过 statsd 热潮，这似乎是一种收集指标并将其输入我们的时间序列数据库的简单方法。发送指标是通过将一个小的 udp 数据包写入守护进程(通常在同一台服务器上运行)来完成的。

我想描述在我的数据路径中发送约 5-10 个 udp 数据包的影响，以了解它会增加多少延迟，并对它的糟糕程度感到惊讶。我知道这是一个非常晦涩的微基准，但只是想大致了解一下它的着陆点。

我的问题

我试图理解为什么将 UDP 数据包发送到本地主机而不是远程主机需要这么长时间(相对而言)。我可以做任何调整来减少发送 UDP 数据包的延迟吗？我正在考虑将指标收集推送到辅助核心或在单独的主机上实际运行 statsd 守护程序的解决方案。

---

我的设置/基准

CentOS 6.5 和一些强大的服务器硬件。
我一直在使用的客户端测试程序可在此处获得:https://gist.github.com/rishid/9178261
使用 gcc 4.7.3 编译 gcc -O3 -std=gnu99 -mtune=native udp_send_bm.c -lrt -o udp_send_bm
接收方正在运行 nc -ulk 127.0.0.1 12000 >/dev/null(每个 IF 的 ip 更改)

我在以下设备上运行了这个微型基准测试。
一些基准测试结果:

• 环回
  • 数据包大小 500//每次 sendto() 的时间 2159 纳秒//总时间 2.159518
• 集成 1 Gb 主板 Controller
  • 数据包大小 500//每个 sendto() 的时间 397 纳秒//总时间 0.397234
• 英特尔 ixgbe 10 Gb
  • 数据包大小 500//每个 sendto() 的时间 449 纳秒//总时间 0.449355
• 带有用户空间堆栈的 solarflare 10 Gb(加载)
  • 数据包大小 500//每个 sendto() 的时间 317 纳秒//总时间 0.317229

Answer 1

写入环回将不是一种用于分析的进程间通信的有效方式。通常，缓冲区在处理之前会被复制多次，并且由于您使用的是 udp，因此您有丢包的风险。您还会对操作系统进行额外的调用，因此会增加上下文切换的风险 (~2us)。

goal is << 5 usec per packet

这是硬实时要求，还是软要求？通常，当您以微秒为单位处理事情时，分析应该是零开销。你在使用 solarflare？，所以我认为你是认真的。我所知道的最好的方法是接入物理线路，并嗅探流量以获取指标。许多产品都可以做到这一点。