我目前正在使用Web服务，返回的结果可能会很大(> 5mb)。

这组数据如此之大且Web服务可以称为同步或者异步是完全有效的，但是我想知道人们对以下几点的看法：

• 如果连接丢失，则必须重新生成并重新发送整个结果集。如果连接丢失或者重置，有什么办法可以执行任何"恢复"操作？
• 发送如此大的结果集是否合适？在生成结果集并将其存储在服务器上，然后客户端可以下载较小数量的结果集并在其末尾重新组合该结果集的情况下，实现某种"分页"会更好吗？

解决方案

回答

对于结果集大小，没有针对5 Mb的硬性规定。超过400 Mb可能很难发送。

我们将自动获得异步处理程序(因为我们使用的是.net)

implement some sort of "paging" where
  the resultset is generated and stored
  on the server and the client can then
  download chunks of the resultset in
  smaller amounts and re-assemble the
  set at their end

对我们来说，这已经发生了-这叫做tcp / ip ;-)重新实现可能会显得过大。

相似地 -

entire resultset will have to be
  regenerated and sent again

例如，如果是MS-SQL，则将生成大多数结果集-然后重新生成它将利用SQL Server中的某些隐式缓存，随后的生成将更快。

在某种程度上，我们可以不必担心这些问题，直到它们浮现为"真正的"问题为止-因为我们使用的平台为我们解决了许多性能瓶颈。

回答

我有点不同意secretGeek的评论：

That's already happening for you -- it's called tcp/ip ;-) Re-implementing that could be overkill.

有时我们可能只想这样做，但实际上只是从UI角度来看。如果我们采用某种方式将数据流式传输到客户端(通过诸如pushlets机制之类的数据)，或者按照建议将其分块为页面，则可以在客户端上加载一些非常小的子集，然后使用以下方法缓慢构建UI完整的数据量。

(从用户的角度来看)这使得UI更加流畅，快速，但是我们必须评估是否值得付出额外的努力……因为我认为这不会花费很多。

回答

因此，听起来我们可能会对在Web方法中添加"起始记录号"和"最终记录号"参数的解决方案感兴趣。 (或者"页码"和"每页结果")

如果后备存储是sql server(甚至mysql)，则它们应该不太困难，因为它们内置了对行编号的支持。

尽管如此，我们应该能够避免在服务器上进行任何会话管理，避免对结果集进行任何显式缓存，而仅依靠后备存储的缓存来简化工作。

回答

我已经看到了这三种方法，即分页，存储和检索以及大量推送。

我认为我们问题的解决方案在一定程度上取决于为什么结果集如此之大以及如何生成结果集。结果会随着时间的推移而增长吗？它们是一次计算全部然后推算吗？是否要在拥有它们后立即将其流回？

分页方法

以我的经验，当客户端需要快速访问与搜索结果中的页面相似的合理大小的结果集块时，使用分页方法是合适的。这里要考虑的是协议的整体闲谈，客户端页面请求之间的整个结果集的缓存和/或者生成结果页面所花费的处理时间。

存储和检索

当结果不是随机访问并且结果集的大小随查询处理而增长时，存储和检索很有用。这里要考虑的问题是客户端的复杂性，是否可以为用户提供部分结果，或者是否需要在将任何内容返回给客户端之前计算所有结果(请考虑从分布式搜索引擎对结果进行排序)。

大规模推

几乎可以肯定，大规模推送方法是有缺陷的。即使客户需要所有信息并且需要将其推送到一个整体的结果集中，我还是建议我们采用" WS-ReliableMessaging"的方法(直接或者通过我们自己的简化版本)并将结果分块。通过这样做你

• 确保碎片到达客户
• 我们可以在收到客户收据后立即丢弃该块
• 可以在服务器和客户端上保留5MB的XML，DOM或者任何内存(假设我们没有以流方式处理结果)，从而减少内存消耗的可能问题。

就像其他人所说的那样，在知道结果集大小，如何生成结果以及将整体性能变为实际问题之前，请不要执行任何操作。