返回较大的结果通过一个WebService [英] Returning Large Results Via a Webservice

问题描述

我的工作，目前的Web服务，并有潜在的，返回的结果可能会相当大（> 5MB）。

这是完全有效的这组数据是这个庞大而Web服务可以被称为无论是同步或异步的，但我不知道是什么人的心思都放在了以下内容：

1. 如果连接丢失， 整个结果将是 再生和再次发送。在那儿 任何方法可以让我做任何形式的 恢复，如果失去连接 或重置？

2. 发送一个结果集，这个大的甚至合适吗？它会更好，以实现某种分页里生成并存储在服务器上的结果集，然后客户端可以下载该结果的块更小的金额和重新组装一套在他们结束？

解决方案

我都看见了这三种方法，分页 存储和检索和大规模推

我觉得解决您的问题，在很大程度上取决于为什么你的结果集是如此之大，它是如何产生一定的抑制作用。做你的结果随着时间的推移，他们在计算全部一次，然后推，做你想做的，只要你让他们流他们回来？

寻呼方法

在我的经验，使用寻呼的做法是合适的，当客户需要快速访问的结果集类似于搜索结果页的合理大小的块。这里考虑是您的协议的整体繁琐，整个结果客户页面请求之间设置的高速缓存，和/或花费来产生结果的一个页面的处理时间。

存储和检索

当结果不是随机接入和结果集中生长在大小为处理查询存储和检索是有用的。问题在这里考虑的是复杂性的客户，如果你能提供给用户的部分结果，或者如果你需要什么返回到客户端之前计算所有结果（觉得从分布式搜索引擎的排序结果）。

海量推

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

1. 确保件到达客户端
2. 能够尽快抛弃块，你从客户拿到收据
3. 可以不必保留5MB的XML，DOM，或任何在内存中（假设你没有处理结果以数据流的方式）在服务器端和客户端减少内存消耗可能出现的问题。

像其他人所说的，虽然，没有做任何事情之前，你知道你的结果集的大小，它是如何产生的，整体性能是实际的问题。

I'm working on a web service at the moment and there is the potential that the returned results could be quite large ( > 5mb).

It's perfectly valid for this set of data to be this large and the web service can be called either sync or async, but I'm wondering what people's thoughts are on the following:

1. If the connection is lost, the entire resultset will have to be regenerated and sent again. Is there any way I can do any sort of "resume" if the connection is lost or reset?

2. Is sending a result set this large even appropriate? Would it be better to 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?

解决方案

I have seen all three approaches, paged, store and retrieve, and massive push.

I think the solution to your problem depends to some extent on why your result set is so large and how it is generated. Do your results grow over time, are they calculated all at once and then pushed, do you want to stream them back as soon as you have them?

Paging Approach

In my experience, using a paging approach is appropriate when the client needs quick access to reasonably sized chunks of the result set similar to pages in search results. Considerations here are overall chattiness of your protocol, caching of the entire result set between client page requests, and/or the processing time it takes to generate a page of results.

Store and retrieve

Store and retrieve is useful when the results are not random access and the result set grows in size as the query is processed. Issues to consider here are complexity for clients and if you can provide the user with partial results or if you need to calculate all results before returning anything to the client (think sorting of results from distributed search engines).

Massive Push

The massive push approach is almost certainly flawed. Even if the client needs all of the information and it needs to be pushed in a monolithic result set, I would recommend taking the approach of WS-ReliableMessaging (either directly or through your own simplified version) and chunking your results. By doing this you

1. ensure that the pieces reach the client
2. can discard the chunk as soon as you get a receipt from the client
3. can reduce the possible issues with memory consumption from having to retain 5MB of XML, DOM, or whatever in memory (assuming that you aren't processing the results in a streaming manner) on the server and client sides.

Like others have said though, don't do anything until you know your result set size, how it is generated, and overall performance to be actual issues.

这篇关于返回较大的结果通过一个WebService的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！