通过WCF进行文件下载比通过IIS慢

下面的方法(我希望它没有犯任何错误,同时为这篇文章大大简化它)正常工作并使用net.tcp协议上的流传输模式进行设置.问题是性能明显差于通过IIS通过http下载相同的文件.为什么会这样,我可以改变什么来改善性能呢？

Stream WebSiteStreamedServiceContract.DownloadFile( string filePath ) {
    return File.OpenRead( filePath );
}

最后,WCF是否负责妥善处理我的流,并且它在这方面做得好吗？如果没有,我应该做什么呢？

谢谢.

经过8个月的处理这个问题,其中3个与微软,这里是解决方案.简短的回答是服务器端(发送大文件的一方)需要使用以下内容进行绑定:

这里的关键是connectionBufferSize属性.可能需要设置其他几个属性(maxReceivedMessageSize等),但connectionBufferSize是罪魁祸首.

服务器端不需要更改代码.

客户端不需要更改代码.

无需在客户端更改配置.

这是一个很长的答案:

我一直怀疑net.tcp对WCF的影响很慢是因为它经常发送小块信息而不是更频繁地发送大量信息,这使得它在高延迟网络(互联网)上表现不佳.事实证明这是真的,但到达那里是一条漫长的道路.

netTcpBinding上有几个属性听起来很有希望:maxBufferSize是最明显的,而maxBytesPerRead和其他人听起来也很有希望.除此之外,还可以创建比原始问题更复杂的流 - 您可以在客户端和服务器端指定缓冲区大小.问题是这些都没有任何影响.一旦你使用netTcpBinding,你就会受到冲击.

原因是在netTcpBinding上调整maxBufferSize会调整协议层上的缓冲区.但是你无法对netTcpBinding做任何调整底层传输层.这就是为什么我们失败了很久才取得进展.

自定义绑定解决了这个问题,因为增加传输层上的connectionBufferSize会增加一次发送的信息量,因此传输更不容易受到延迟的影响.

在解决这个问题时,我注意到maxBufferSize和maxBytesPerRead确实对低延迟网络(和本地)产生了性能影响.Microsoft告诉我,maxBufferSize和connectionBufferSize是独立的,并且它们的值的所有组合(彼此相等,maxBufferSize大于connectionBufferSize,maxBufferSize小于connectionBufferSize)是有效的.我们成功使用了65536字节的maxBufferSize和maxBytesPerRead.但是,这对高延迟网络性能(原始问题)的影响非常小.

如果您想知道maxOutputDelay的用途,那么它是在框架抛出IO异常之前分配给填充连接缓冲区的时间量.因为我们增加了缓冲区大小,所以我们还增加了分配给缓冲区的时间.

使用此解决方案,我们的性能提高了约400%,现在略好于IIS.还有其他一些因素影响IIS上的HTTP和WCF over net.tcp(以及WCF over http)的相对和绝对性能,但这是我们的经验.