每个单独的 TCP 套接字的多个挂起读取或多个挂起写入的性能优势?
Posted
技术标签:
【中文标题】每个单独的 TCP 套接字的多个挂起读取或多个挂起写入的性能优势?【英文标题】:Performance benefit of multiple pending reads or multiple pending writes per individual TCP socket? 【发布时间】:2014-08-14 00:12:25 【问题描述】:IOCP 对许多连接都很好,但我想知道的是,允许每个 TCP 套接字的多个挂起接收或多个挂起写入是否有显着的好处,或者如果我只是允许我真的不会失去性能每个套接字一个挂起的接收和一个挂起的发送(这确实简化了事情,因为我不必处理乱序完成通知)?
我的一般用例是 2 个工作线程为 IOCP 端口提供服务,处理多个连接(超过 2 个但少于 10 个),其中传输的数据是两种形式的以太:一种是频繁的非常小的消息(如果可以手动,但通常需要发送足够多的频率,每次发送的数据仍然很小),另一个是传输大文件。
【问题讨论】:
【参考方案1】:除非您计划关闭网络堆栈的 recv 缓冲,否则多个待处理的 recv 的用途往往有限,在这种情况下它们是必不可少的。请记住,如果您决定发出多个待处理的 recv,那么您必须做一些工作以确保以正确的顺序处理它们。虽然 recv 将按照发出它们的顺序从 IOCP 完成线程调度问题可能意味着它们由不同的 I/O 线程以不同的顺序处理,除非您积极工作以确保不是这种情况,请参阅@987654321 @了解详情。
多个挂起的发送对于充分利用 TCP 连接的可用 TCP 窗口(并以可能的最大速率发送)更有用,但前提是您有大量数据要发送,前提是您希望尽可能高效地发送它并且仅当您注意确保没有太多待处理的写入时。请参阅here,了解如果您不主动管理待处理写入数量可能会遇到的问题的详细信息。
【讨论】:
对于延迟是最重要因素(比如控制信号或其他近实时信息)的流媒体呢?我认为这会很有用,因为我想在不等待上一个完成的情况下启动下一个发送。 是的,这将是一个有用的场景。恕我直言,它总是有用的;)如果稍微复杂一点......【参考方案2】:对于少于 10 个连接和 TCP,即使在高速率下您也可能不会感觉到任何差异。通过简单地增加缓冲区大小,您可能会看到更好的性能。
如果您的应用程序突发且处理成本高昂,则排队 I/O 会有所帮助。基本上,它可以让您预先执行成本高昂的工作,这样当突发出现时,您将在 I/O 上使用少量 CPU,并在处理上尽可能多地使用它。
【讨论】:
以上是关于每个单独的 TCP 套接字的多个挂起读取或多个挂起写入的性能优势?的主要内容,如果未能解决你的问题,请参考以下文章
boost asio ssl::stream<tcp::socket> 是不是支持多个挂起的 http::async_write 调用?