9

我目前正在开发 Web 服务,返回的结果可能会非常大(> 5mb)。

这组数据这么大是完全有效的,并且 Web 服务可以称为同步或异步,但我想知道人们对以下方面的想法是什么:

  1. 如果连接丢失,则必须重新生成整个结果集并再次发送。如果连接丢失或重置,有什么办法可以做任何类型的“恢复”?

  2. 发送这么大的结果集是否合适?实现某种“分页”会更好吗?结果集生成并存储在服务器上,然后客户端可以以较小的数量下载结果集的块并在其末端重新组装集?

4

4 回答 4

3

我见过所有三种方法,分页存储和检索以及大规模推送

我认为您的问题的解决方案在某种程度上取决于您的结果集为何如此之大以及它是如何生成的。您的结果是否会随着时间的推移而增长,它们是一次计算然后推送的,您是否想在获得它们后立即将它们流回?

分页方式

根据我的经验,当客户端需要快速访问与搜索结果中的页面类似的结果集中大小合理的块时,使用分页方法是合适的。此处的考虑因素是您的协议的整体健谈性、客户端页面请求之间整个结果集的缓存和/或生成结果页面所需的处理时间。

存储和检索

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

大规模推动

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

  1. 确保碎片到达客户手中
  2. 一旦您从客户那里收到收据,就可以丢弃该块
  3. 可以减少内存消耗的可能问题,因为必须在服务器和客户端保留 5MB 的 XML、DOM 或内存中的任何内容(假设您没有以流方式处理结果)。

就像其他人所说的那样,在您知道结果集大小、生成方式以及整体性能成为实际问题之前,不要做任何事情。

于 2009-05-28T13:47:30.103 回答
2

作为结果集大小,没有严格的法律规定 5 Mb。超过 400 Mb 可能很难发送

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

实现某种“分页”,其中生成结果集并将其存储在服务器上,然后客户端可以以较小的数量下载结果集的块并在其末端重新组装结果集

这已经发生在你身上——它被称为 tcp/ip ;-) 重新实现可能是矫枉过正。

相似地 -

整个结果集必须重新生成并再次发送

例如,如果生成大部分结果集的是 MS-SQL,那么重新生成它将利用 SQL Server 中的一些隐式缓存,并且后续生成会更快。

在某种程度上,您可以不必担心这些问题,直到它们作为“真正的”问题浮出水面——因为您使用的平台为您解决了很多性能瓶颈。

于 2008-08-15T00:18:19.303 回答
0

我有点不同意secretGeek 的评论:

这已经发生在你身上——它被称为 tcp/ip ;-) 重新实现可能是矫枉过正。

有时您可能只想这样做,但实际上只是从 UI 角度来看。如果您实现某种方式将数据流式传输到客户端(通过类似 pushlets 机制),或者按照您的建议将其分块到页面中,然后您可以在客户端上加载一些非常小的子集,然后慢慢构建 UI全部数据量。

这使得 UI 更流畅、更快速(从用户的角度来看),但您必须评估额外的努力是否值得……因为我认为这不会是微不足道的工作量。

于 2008-08-15T00:31:36.360 回答
0

因此,听起来您会对将“起始记录号”和“最终记录号”参数添加到您的 Web 方法的解决方案感兴趣。(或“页码”和“每页结果”)

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

尽管如此,您应该能够避免在服务器上进行任何会话管理,避免对结果集进行任何显式缓存,并且只依靠后备存储的缓存来保持简单。

于 2008-08-15T01:40:05.410 回答