WCF HttpTransport:stream式传输与缓冲传输模式

我有一个自托pipe的WCF服务(v4框架),通过基于HttpTransport的自定义绑定公开。 该绑定使用了一个自定义的MessageEncoder ,它几乎是一个BinaryMessageEncoder ,并增加了gzip压缩function。

Silverlight和Windows客户端使用Web服务。

问题 :在某些情况下,服务必须返回非常大的对象,偶尔在响应多个并发请求时(即使任务pipe理器报告进程为〜600 Mb),抛出OutOfMemoryexception。 自定义编码器发生exception时,消息即将被压缩,但我相信这只是一个症状,而不是原因。 例外情况是“未能分配x Mb”,其中x为16,32或64,而不是过大的数额 – 因此,我相信其他的东西已经把这个过程放在了一些极限之前。

服务端点定义如下:

 var transport = new HttpTransportBindingElement(); // quotas omitted for simplicity var binaryEncoder = new BinaryMessageEncodingBindingElement(); // Readerquotas omitted for simplicity var customBinding = new CustomBinding(new GZipMessageEncodingBindingElement(binaryEncoder), transport); 

然后我做了一个实验:将TransferModeBuffered更改为StreamedResponse (并相应地修改了客户端)。 这是新的服务定义:

 var transport = new HttpTransportBindingElement() { TransferMode = TransferMode.StreamedResponse // <-- this is the only change }; var binaryEncoder = new BinaryMessageEncodingBindingElement(); // Readerquotas omitted for simplicity var customBinding = new CustomBinding(new GZipMessageEncodingBindingElement(binaryEncoder), transport); 

神奇的是,没有OutOfMemoryexception了 。 对于小消息来说,该服务稍微慢一点,但随着消息大小的增长,差异会越来越小。 行为(包括速度和OutOfMemoryexception)是可重复的,我对这两种configuration都做了几次testing,结果是一致的。

问题解决了,但是:我不能解释自己在这里发生了什么。 我的惊讶源于我没有以任何方式改变合同的事实。 也就是说,我没有像一个Stream参数一样创build一个合约,就像通常为stream式传输的消息所做的那样。 我仍然使用具有相同DataContract和DataMember属性的复杂类。 我只是修改了端点 ,就这些。

我以为设置TransferMode只是一个方法来启用适当形成的合同stream,但显然不止这些。 任何人都可以解释一下,当你改变TransferMode时候实际发生了什么?

当你使用'GZipMessageEncodingBindingElement'时,我假设你正在使用MS GZIP示例。

看看GZipMessageEncoderFactory.cs中的DecompressBuffer() ,你就会明白缓冲模式下发生了什么。

举例来说,假设您有一个未压缩大小为50M,压缩大小为25M的消息。

DecompressBuffer将接收(1) 25M大小的“ArraySegment缓冲区”参数。 然后,该方法将创build一个MemoryStream,使用(2) 50M解压缩缓冲区。 然后它将执行一个MemoryStream.ToArray(),将内存stream缓冲区复制到一个新的(3) 50M大字节数组中。 然后从ATTREAST(4) 50M +的BufferManager中获取另一个字节数组,实际上,它可以更多 – 在我的情况下,对于50M数组,总是67M。

在DecompressBuffer的末尾,(1)将被返回到BufferManager(这似乎永远不会被WCF清除),(2)和(3)受到GC(这是asynchronous的,如果你比GC快,即使清理了足够的内存,也可能会遇到OOMexception)。 (4)大概会被返回给你的BinaryMessageEncodingBindingElement.ReadMessage()中的BufferManager。

综上所述,对于你的50M消息来说,你的缓冲场景将暂时占用25 + 50 + 50 +例如65 = 190M的内存,其中一些需要asynchronousGC,一些由BufferManagerpipe理,最糟糕的情况是它会在内存中保留大量未使用的数组,这些数组在后续请求中不可用(例如太小),也不符合GC的条件。 现在想象你有多个并发请求,在这种情况下,BufferManager将为所有并发请求创build单独的缓冲区,除非你手动调用BufferManager.Clear(),否则永远不会被清理,我不知道有什么办法可以做到这一点与WCF使用的缓冲区pipe理器,请参阅此问题: 如何防止WCF客户端应用程序中的BufferManager / PooledBufferManager浪费内存? ]

更新:迁移到IIS7 Http Compression( wcf条件压缩 ) 内存消耗后,cpu加载和启动时间下降 (没有数字方便),然后从缓冲迁移到streamTransferMode( 我怎样才能防止我WCF中的BufferManager / PooledBufferManager客户端应用程序从浪费内存? ) 我的WCF客户端应用程序的内存消耗已经从630M(峰值)/ 470M(连续)下降到270M(峰值和连续)

我有一些WCF和stream媒体的经验。

基本上,如果您没有将TransferMode设置为stream,那么它将默认为缓冲。 所以,如果你发送大量的数据,它将在你的内存中build立数据,然后一旦所有的数据被加载并准备好发送,就发送它。 这就是为什么你的内存错误,因为数据是非常大的,而不是你的机器的内存。

现在,如果您使用stream式传输,那么它会立即开始将数据块发送到另一个端点,而不是将其缓冲起来,从而使内存使用量极小。

但这并不意味着接收器也必须设置为stream式传输。 如果他们没有足够的内存来存储数据,他们可能会被设置为缓冲区,并会遇到与发件人相同的问题。

为了获得最好的结果,应该设置两个端点来处理数据stream(对于大数据文件)。

通常,对于stream式处理,您使用MessageContracts而不是DataContracts因为它使您可以更好地控制SOAP结构。

有关详细信息,请参阅MessageContracts和Datacontracts上的这些MSDN文章。 这里有更多关于缓冲vsstream的信息 。

我认为(我可能是错的),限制用户只是一个Stream参数在使用Streamed传输模式的操作契约中,来自于WCF将stream数据放入SOAP消息的主体部分并开始将其作为用户开始阅读stream。 所以,我认为他们很难在一个数据stream中复制任意数量的数据stream。 例如,假设您有一个具有3个stream参数的操作契约,并且客户端上的三个不同线程开始从这三个stream中读取。 你怎么能这样做,而不使用一些algorithm和额外的程序来复用这三个不同的数据stream(WCF现在没有)

至于你的其他问题,很难说没有看到你的完整的代码实际上正在进行,但我认为通过使用gzip,你实际上是压缩所有的消息数据到一个字节数组,把它交给WCF和客户端当客户端请求SOAP消息时,底层通道打开一个stream来读取消息和WCF通道进行stream式传输,开始stream式数据,因为它是消息的主体。

无论如何,你应该注意到设置MessageBodyMember属性只是告诉WCF这个成员应该作为SOAP主体进行stream式传输,但是当你使用自定义的编码器和绑定时,大多数情况下你会select传出消息的样子。

caching:上传/下载前需要将整个文件放入内存中。 这是安全地传输小文件非常有用的方法。

stream式传输文件可以以块的forms传输。