2

我使用的是 64 位 Linux Linux scv 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux，并且有两个进程使用在同一物理主机上运行的套接字。

一个进程 ( A ) 在 TCP/IP 套接字上发送以下数据：

  1. 276 字节
  2. 16 字节

这是在进程A的 0.000023 秒内完成的。数据正在发送调用 2 次send套接字 API。

另一个进程 ( B ) 通过epoll接收数据，使用epoll_wait(efd, events, 10, 5). 数据接收如下（时间与clock_gettime(CLOCK_REALTIME, &cur_ts);，重要的是相对差异）：

  1. 从 8051.177743 (276) 的套接字缓冲区读取数据
  2. 再次拨打 epoll 8051.177763
  3. 从套接字缓冲区读取数据 8051.216250 (16)

使接收过程滞后0.038507 秒。基本上，如果发送过程A花费的时间少于ms，则在接收端epoll接收数据会增加大约 0.038 s 的额外延迟。

这是预期的吗？我究竟做错了什么？
或者我该如何改善这种情况？

谢谢

4

1 回答 1

-1

Is this expected? ...

Yes. I would expect that. Here's why:

What am I doing wrong? ...

epoll was designed to be used in situations where large numbers of file descriptors need to be watched. That's what it's suitable for, and it seems to me that the situation you're using it for isn't that situation.

... how can I improve the situation?

If you want to improve the performance, use the right tool for the job. Don't use epoll for a single socket. Just use plain-old vanilla recv. If you're handling two or three sockets, consider using poll or select. If you're venturing into hundreds, then you might want to consider using epoll or kqueue.

于 2013-04-01T14:36:37.710 回答