Nito.AsyncEx 的 AsyncProducerConsumerQueue 性能是否足以处理千兆字节？答案

【问题标题】：Is Nito.AsyncEx's AsyncProducerConsumerQueue performant enough to handle gigabytes of bytes?Nito.AsyncEx 的 AsyncProducerConsumerQueue 性能是否足以处理千兆字节？
【发布时间】：2020-02-12 15:29:06
【问题描述】：

AsyncProducerConsumerQueue<byte> (maxCount: 10*1024*204) 是为处理千兆字节而设计的，还是有更好的方法来为千兆字节创建流队列？将一些大小的 byte[] 放入队列中会更好吗？

我打电话给await Dequeue 十亿次听起来很奇怪......

【问题讨论】：

标签： nito.asyncex

【解决方案1】：

AsyncProducerConsumerQueue - 与 AsyncEx 中的所有其他类型一样 - 是为可维护性和正确性而非性能而编写的。

对于高性能异步队列，我推荐Channels。你仍然会多次调用await，但Channels 使用ValueTask<T>，这在同步情况下非常高效。

【讨论】：

如果有人过来阅读我的问题和这个答案：等待流中的每个单个字节的性能不够。我们最终将每个 4096 字节的字节数组放入通道中，这就像一个魅力。再次感谢斯蒂芬指出频道！
@D.R.：您使用的是 .NET Core 3.0 之前的版本吗？ 3.0 got some performance improvements that help Channels be even more efficient than they already were.
我们正在使用 .NET Framework 4.7.2 + 最新版本的 System.Threading.Channels NuGet 包。不知道他们是否也应该进行这些改进。
@D.R.：不，那些性能改进只是（并且永远是）.NET Core。
性能提升确实非常好，我在博客文章中提供的综合基准测试中看到了 0.3 到 0.5 的比率。但是，到目前为止，这还不足以通过通道逐个字节地传输千兆字节。我们使用 Writer->Channel->Reader->StreamContent->HttpClient->WebService 设置在大约 2 分钟内将 800MB 传输到 localhost Web 服务（应该归咎于流媒体）。切换到 4096 字节的 byte[] 后，我们的时间缩短到了 8 秒（大约是我们的环回在最大速率下给我们的时间）。