WCF NetTcpBinding 缓冲与流式性能问题答案

【问题标题】：WCF NetTcpBinding Buffered vs Streamed performance problemsWCF NetTcpBinding 缓冲与流式性能问题
【发布时间】：2011-01-07 21:13:32
【问题描述】：

我使用NetTcpBinding 和System.IO.Stream 对象中的Streamed TransferMode 编写了一个可以转换任意大小文件的WCF 服务。

在运行性能测试时，我发现了严重的性能问题。然后我决定用 Buffered TransferMode 进行测试，发现性能快了两倍！

因为我的服务应该传输大文件，我不能停留在缓冲传输模式，因为服务器端和客户端的大文件的内存管理开销。

为什么 Streamed TransferMode 比 Buffered TransferMode 慢？我可以做些什么来提高 Stremed 的性能？

【问题讨论】：

你具体测量了什么？消息的传输？从客户端到服务器的往返行程并返回给客户端？
我测量对服务器的调用并等待 Stream 返回，然后在 using 块中读取具有 64k 缓冲区的整个流。
@DxCK：现在你的意见是什么？应该使用哪一个？我有要传输的大数据和小数据。

标签： c# .net wcf performance streaming

【解决方案1】：

您正在流式传输的数据块有多大？您可以尝试不同的块大小和不同的策略。
另外，考虑使用Asynch IO 来填充要传输的缓冲区，或者在传输之后。

我的意思是，如果你的流算法是串行的，像这样：

1. Fill a chunk
2. send the chunk
3. get confirmation
4. more chunks?  Go to step 1

...那么你有很多不必要的延迟。如果您可以并行填充块并发送块，那么您将能够减少等待。异步 IO 是一种方法。您将发生两个并行的工作流。从概念上讲，它可能看起来像这样：

Filling Chunks                              Sending Chunks
  1. call BeginRead                           1. get next chunk
  2. wait for callback                        2. send it
  3. more to read? yes -> go to step 1        3. await confirmation
  4. done                                     4. more? go to step 1

但是使用异步 IO，这些实际上可以由同一个线程驱动。

记住这一点：

你读了吗MS's article on the topic of large data streaming in WCF?

【讨论】：

我的测试除了 WCF 之外没有其他 IO。传输的 Stream 包含比使用 Random.NextBytes() 方法创建的随机字节。无论如何，只要将配置更改为“缓冲”，完全相同的代码就会更快地运行。
将我的cmets中的“IO”替换为“Random.NextBytes()”，原理依然有效。就您而言，您是否一次对一小部分执行 Random.NextBytes() ？如果是这样，请考虑使用异步来消除操作的序列化。
我对各种大小执行了 Random.NextBytes()：64k、350k、512k、1MB、2MB、5MB、10MB，然后创建了一个 MemoryStream 并将流提供给 WCF。 WCF 完成所有其余工作（读取等）。另一方（服务器或客户端）正在读取流，我发现各种缓冲区大小之间没有性能差异。所有这些不同大小的结果都相似：Buffered 比 Streamed 快 2 倍。
这确实是一个人为的、不切实际的场景。性能差异的解释可能都是由于 WCF 在分块流时所做的上下文切换，而不是在将流读入一个大缓冲区时所做的。