异步/等待模式是否会对次要工作单元造成性能损失？

Question

我正在寻找关于异步/等待有意义的"工作负载阈值"(例如释放IO完成端口并避免线程饥饿)与工作单元执行过于简单/便宜之间的一些指导,因此同步执行是一个更好的选择.

换句话说,当与相对快速/资源廉价的工作单元结合使用时,async/await的使用是否会导致性能下降,并且简单地同步执行工作将是首选方法？

示例(所有在一个方法中,都与await异步):

• 保存对DB的一些小更新
• 使用读取非常小的文件上传到流 ReadAsStreamAsync
• 使用将文件流复制到文件流 CopyToAsync
• 刷新写入器流使用 FlushAsync

Answer 1

我建议您不是从时序角度来看,而是从I/O-vs-CPU的角度来看.

CPU绑定方法自然是同步的; I/O绑定方法自然是异步的.

我假设您的环境是服务器端,基于您的示例:

• 保存对DB的一些小更新.自然异步:网络(或至少是进程外)通信,争用的可能性,磁盘I/O.
• 使用ReadAsStreamAsync将非常小的文件上载读取到流中.自然异步:网络通信.
• 使用CopyToAsync将读取流复制到文件流.自然异步:争用的可能性,磁盘I/O.
• 使用FlushAsync刷新写入器流.自然异步:争用的可能性,磁盘I/O.

所有这些都是自然异步操作,因此它们都应该异步实现.CPU比内存快得多,这比网络或磁盘I/O快得多.因此,如果同步实现自然异步方法,则会阻塞线程.这不是世界末日,但线程池必须补偿它是否被阻塞太长时间,并且你"保存"的唯一时间是线程切换时间,这将比任何网络短几个数量级或磁盘I/O可能是.

另一件需要考虑的事情是不可预测的延迟,这通常是由于资源争用而发生的.如果另一个进程同时写入db,该怎么办？如果文件上传时出现路由打嗝,需要重新传输数据包怎么办？如果在您尝试写入输出文件时磁盘进行碎片整理会怎样？异步操作倾向于像这样不可预测,并且async代码确保您不会比预期更长时间地阻塞线程.

总之:使用同步代码进行同步(CPU绑定)工作,使用异步代码进行异步(I/O绑定)工作.