通过 ASMX Web 服务传输大型数据集的最佳方式是什么？答案

【问题标题】：What's the best way to transfer a large dataset over an ASMX web service?通过 ASMX Web 服务传输大型数据集的最佳方式是什么？
【发布时间】：2011-03-04 06:30:14
【问题描述】：

我继承了一个与 Web 服务对话的 C# .NET 应用程序，而该 Web 服务与 Oracle 数据库对话。我需要在 UI 中添加一个导出功能，以生成一些数据的 Excel 电子表格。

我创建了一个 Web 服务函数来运行数据库查询，将数据加载到 DataTable 中，然后返回它，这对于少量行工作正常。但是，在完整运行中有足够的数据，客户端应用程序会锁定几分钟，然后返回超时错误。显然这不是检索如此大的数据集的最佳方式。

在我继续提出一些不可靠的方法来拆分呼叫之前，我想知道是否已经有一些东西可以处理这个问题。目前我正在考虑 startExport 函数，然后重复调用 next50Rows 函数，直到没有数据为止，但是由于 Web 服务是无状态的，这意味着我将不得不保留某种 ID 号并处理关联的权限。这意味着我不必将整个数据集加载到 Web 服务器的内存中，这是一件好事。

因此，如果有人知道通过 N ASMX Web 服务检索大量数据（表格格式）的更好方法，请告诉我！

【问题讨论】：

多少数据？你确定这是数据量，不可能是查询或其他原因造成的吗？
可能是查询，只有几千行数据。它在 100Mbps 网络上仅以大约 100k/秒的速度返回。但我想问题还是一样 - 数据需要很长时间才能到达，客户端应用程序没有得到任何反馈来知道发生了什么，所以它最终会超时。

标签： .net web-services asmx large-data-volumes

【解决方案1】：

几年前我们有过这种确切的业务场景，我会告诉你我们做了什么。

尝试限制传输的数据量
如果您要传输 n 个表，请将它们拆分为 n 个数据表并一次传输一个数据表。
在传输之前压缩您的数据集/数据表。这会产生巨大的（巨大的）影响。另一方面，将字节流解压缩回数据集/数据表。也不要使用 .NET 的内置压缩 - 使用 SharpZipLib。它提供了更好的结果。
此外，您可以异步执行传输以防止客户端锁定。

我们的客户多年来一直在使用上述解决方案，没有出现任何问题。

【讨论】：

感谢您的建议。通常这可以正常工作，但在我的特殊情况下，它只是一个需要转移的大表，因此不能将其拆分为较小的表。由于它仅在 100Mbps 网络上以 100k/秒的速度运行，我认为压缩不会有帮助，即使是异步的，它仍然需要足够长的时间才能使调用超时:-(

【解决方案2】：

我怀疑您只是想异步调用 Web 服务，这样您的应用程序就不会在 UI 上阻塞，而这一切都在进行。看看http://msdn.microsoft.com/en-us/library/ms233842.aspx 看看是否有帮助。

【讨论】：

-1：这是关于 ASMX Web 服务的，它是一项遗留技术。请参阅msdn.microsoft.com/en-us/library/7bkzywba.aspx 和许多其他页面。
@Malvineous 您使用的是 asmx 还是 WCF？我可以使用 WCF 链接更新答案...
我正在使用 ASMX（我认为，Web 服务 URL 以 .asmx 结尾），因为这是应用程序附带的。将调用放在另一个线程中可能不会有太大帮助，因为我仍然会在客户端收到超时错误。

【解决方案3】：

我建议将任务卸载到 SSRS，它可以毫无问题地处理长时间运行的查询。您可以使用报告生成器构建报告，然后使用 .NET 应用程序调用 SSRS Web 服务运行您的报告并以 Excel 格式（作为字节数组）导出结果。有关使用 .asmx 服务的示例代码，请参阅this page，有关使用 WCF 调用 SSRS，请参阅 this page。

您还应该在单独的线程中调用您的 Web 服务，以避免占用您的 UI。

【讨论】：

【解决方案4】：

请参阅 MSDN 库中的“Large Data and Streaming”。

如果您对大数据传输的性能感兴趣，请不要使用 ASMX Web 服务。

【讨论】：

【解决方案5】：

我推荐 WCF 数据服务（或现在的任何名称）。您可以公开一个 oData 端点（如果您在 web 服务的两侧都有 .NET），可以为您提供透明的请求限制（服务器限制单个调用中的响应数量，客户端会根据需要自动发出额外的请求）。它还为您提供了一个非常灵活的IQueryable 风格的界面。

【讨论】：

【解决方案6】：

问题很常见：您有很多数据要返回给用户。

如果你幸运的话，你可以通过增加 web 服务超时来逃脱。否则，一次将分页数据返回给用户的解决方案是否适合您的要求？在这种设计中，调用者将负责指定起始页，以及每页向您的 Web 服务提供多少行数据。

见Pagination Queries和Pagination tips

但是，如果您不限于使用 Web 服务作为解决方案，那么您可能希望研究向您的用户提供 Reporting Services。绝对值得您花时间研究这个替代选项:)

【讨论】：

感谢您的建议。分页并不是很理想，因为数据来自 Oracle 视图，并且大部分的减速是运行视图。所以即使它被分页，每一页都会很慢（除非我在调用之间以某种方式保持 Oracle 光标打开......）
@Malvineous，您不必在通话之间保持光标打开。请参阅上面的更新链接。希望对你有帮助