WCF - 返回大图片 - 您的经验和提示

Question

我们正在使用WCF服务层从存储库返回图像。有些图像是彩色的，多页的，几乎都是TIFF格式。我们经历了缓慢 - 许多问题之一。

1。）通过WCF返回图像有什么经验 2.）您对返回大图像有什么建议吗？ 3.）所有消息都通过SOAP序列化正确？
4.）wcf在压缩大型tiff文件方面做得不好吗？

全部谢谢！

Answer 1

好的只是为了获得ZombieSheep和Seba Gomez的回复，你一定要看看你的数据流。通过这样做，您可以将GZipStream无缝集成到流程中。在客户端，您可以反转压缩过程并将流转换回所需的图像。

通过使用流式传输，可以使用选定数量的类作为参数/返回类型，并且您需要在整个过程中修改绑定。

以下是启用流式传输的MSDN site。 This是MSDN页面，描述了对流式合同的限制。

我假设您也在控制客户端代码，如果您不这样做，这可能会非常困难。当我控制服务器和客户端时，我只使用了流式传输。

祝你好运。

Answer 2

如果您使用其他.Net程序集作为客户端，则可以使用两种方法返回大量数据，流或MTOM。

Streaming将允许您传递TIFF图像，就像它是本地文件系统上的普通文件流一样。有关选择及其优缺点的详细信息，请参阅here。

不幸的是，考虑到已经提出的观点，你仍然需要传输大量数据，而我无法看到任何解决方法。

Answer 3

我只想补充一点，确保您的数据流式传输而不是缓冲是非常重要的。

我在某处读到，即使您将transferMode设置为'Streamed'，如果您不使用Stream本身，Message或IXmlSerializable的实现，该消息也不会流式传输。

请务必牢记这一点。

Answer 4

你使用什么绑定？ WCF会有一些开销，但是如果你使用带有MTOM的basic-http，那么你将失去大部分的base-64 overead。你仍然会有标题等。

另一种选择是（等待它......）不要在这里使用WCF - 也许只是一个返回二进制文件的处理程序（ashx等）。

重新压缩 - WCF本身不会有太多压缩;传输可能，特别是通过IIS等启用了gzip - 然而，图像因难以压缩而臭名昭着。

Answer 5

在我之前的一个项目中，我们遇到了类似的问题。我们在C＃中有一个Web服务，它接收了媒体请求。介质可以是文件到图像，使用BLOB列存储在数据库中。最初，处理媒体检索请求的Web方法从BLOB读取块并返回给调用者。这是一次往返服务器。这种方法的问题在于客户端没有对操作进度的反馈。

  

计算机没有问题   无法解决的科学问题   额外的间接水平。

我们首先用三种方法重构方法。

Method1 设置来电者和网络服务之间的对话。这包括有关请求的信息（如媒体ID）和功能交换。 Web服务使用勾选的Id进行响应，该ID用于未来请求的调用者。此初始调用用于资源分配。

连续调用

Method2 ，直到为媒体检索更多内容。该调用包括有关当前偏移量的信息以及调用 Method1 时提供的滴答ID。返回更新当前位置。

当 Method2 报告请求媒体的读取已完成时，将调用

Method3 来完成请求。这释放了分配的资源。

这种方法很实用，因为您可以立即向用户反馈有关操作进度的信息。您有一个奖励是将请求拆分为不同线程中的 Method2 。比一些BitTorrent客户端可以报告的进度要多。

---

根据BLOB的大小，您可以选择一次性从数据库加载它或reading it also by chunks。这意味着您可以使用基于给定水印（BLOB大小）选择一次性或通过块加载它的平衡机制。

---

如果仍然存在性能问题，请考虑使用GZipStream打包结果或阅读message encoders，并特别注意二进制和消息传输优化机制（MTOM）。