F#结合NpgSQL实现批量插入时，异步操作是否具备实际性能意义？

关于Npgsql二进制导入异步API的性能疑问解答 #

你对BinaryImport写入行为的认知存在部分偏差，异步API在此处的使用是合理的，核心原因如下：

• 写入操作不只是本地缓冲
  Npgsql的二进制写入器内部存在固定大小的网络发送缓冲区，当你循环写入的总数据量超过缓冲区阈值时，StartRowAsync、WriteAsync会自动触发底层网络IO，将已缓冲的批量数据同步到PostgreSQL服务端，此时的异步等待就是真实的非阻塞IO操作，不会占用线程池线程等待IO完成。
• 空等待的开销可以忽略
  如果单次写入的positions数据量很小，所有写入操作都没有触发缓冲区刷新，那么已经同步完成的Task在F#异步状态机中的await开销非常低，几乎不会对性能造成可观测的影响。
• 同步版本存在稳定性隐患
  如果为了省掉微小的await开销换成同步的Write/StartRow方法，一旦后续业务迭代中单次写入的数据量变大，触发缓冲区刷新时就会阻塞当前线程，在高并发服务场景下极易引发线程池饥饿，导致整体服务吞吐量暴跌，反而得不偿失。

如果要做极致优化，你可以主动调整writer的缓冲区大小匹配你的业务单批次写入数据量，降低触发缓冲区刷新的频率，但是不需要把异步API换成同步版本。

内容的提问来源于stack exchange，提问作者Thomas