Web 服务：更频繁的“小”调用，或更不频繁的“大”调用答案

【问题标题】：Web Services: more frequent "small" calls, or less frequent "big" callsWeb 服务：更频繁的“小”调用，或更不频繁的“大”调用
【发布时间】：2010-03-22 17:56:54
【问题描述】：

一般来说，是让 Web 应用程序对 Web 服务进行大量调用以获取较小的数据块，还是让 Web 应用程序进行更少的调用并获取更大的数据块更好？

特别是，我正在构建一个 Silverlight 应用程序，该应用程序需要从服务器获取大量数据以响应用户创建的查询。每个查询可以返回几百到几千条记录。每条记录都有大约 30 个字段，主要是十进制类型的数据。我之前遇到过响应的负载大小超过服务允许的最大值的情况。

我想知道是否最好（对于服务器/客户端/Web 服务更有效）垂直切割此有效负载 - 每次调用时获取单个字段的所有值 - 或水平 - 获取成批的完整记录每次通话。还是有关系？

【问题讨论】：

标签： silverlight silverlight-3.0 web-services

【解决方案1】：

我惊讶地发现，为了提供更好的过滤器，将所需的数据量减少 2 倍甚至 4 倍几乎总是比调用次数加倍更快。

我发现我可以在发出一个新请求的同时转移 200K。大多数经过微调的请求需要大约 3K，而当然的请求可能需要 50-100K。

如果您超过有效负载大小，请增加有效负载大小或在服务器上构建流式 CGI。这样比较好。

【讨论】：

【解决方案2】：

这绝对很重要。您不希望 Web 服务过于冗长 - 对于小的请求，您可能会发现延迟最终会比处理请求所花费的时间更长。另一方面，显然您不想返回不需要的数据。需要找到一个平衡点，这通常涉及客户端能够以相当详细的方式从服务器指定他们想要的内容 - 或者能够在一个 Web 请求中有效地发送“一批”请求。

【讨论】：

我担心的部分原因是 Web 服务调用的频率可能会以某种方式使服务器陷入困境。但与这种担忧相反的是，Web 服务架构旨在处理大量流量。由于这个网站永远不会是一个高流量的网站，我的结论是，聊天网络服务的唯一缺点是用户可能会遇到延迟。这是正确的吗？
@Klay：嗯，我认为“唯一的缺点”可能夸大了它 - 服务器和客户端上的每个请求的开销可能不仅仅是延迟，但这可能是最大的一个.

【解决方案3】：

获得更小的数据集意味着用户将不得不等待更少的时间；这很好。

但获得小数据集意味着他将不得不更频繁地等待。

一种可能性是结合使用这两种方法，例如：

对于第一个请求，只获取一个小数据集，以便能够更快地显示一些信息
并且，对于下一个请求，获取更大的数据集，以减少 HTTP 请求
- 这样，当那些 （稍长） 请求发生时，用户就已经有了要阅读的内容。

【讨论】：

我喜欢这里的“感知响应”概念。

【解决方案4】：

我会说做一些类似分页的事情（一次显示 X 条记录）。这将导致“小”调用，因为用户只会在需要时请求数据。这真的取决于你的情况。他们是否需要一次查看所有数据，还是一次只能查看一小部分数据？

请记住：小块 = 更少等待一些数据。

【讨论】：

这个应用程序不适合分页，因为我在高度交互的地图上绘制了数千个点。我需要一次显示所有的点。而且我不能为此使用基于图像的地图服务，因为它们的交互性不够。
也许不是分页，而是限制地图上点的半径？想想谷歌地图的工作原理。这当然是假设您将“放大”地图的某个区域。
不要不欣赏，但你没有解决我问的问题。我知道分页是什么，并且我已经在应用程序的其他地方成功地使用了它。问题不在于如何最小化发送的数据量，而是如何最好地发送大型原子数据集。