WCF 服务，一个大请求还是很多小请求哪个更好？
我正在检查一些代码，其中我们在从 WCF Web 服务返回数据时遇到了一些问题。目前，该服务创建一个对象列表，将它们序列化（作为记录的 JSON）并在线返回整个序列化列表。显然，当有大量数据时，用户会遇到配额限制问题。
我正在考虑更改它，以便服务一次返回一个项目，这将在循环中发送一堆请求，一次将一个对象添加到列表中，直到完成。
显然，在场景一中，我们向服务发出一个请求，该请求有可能返回大量数据并超出配额。在另一种情况下，我们从未达到配额，但请求应用程序将在单独的请求流中请求一个又一个的数据项。
为了说明这一点，我们有一个包含各种项目类型的项目列表，这些类型的价格也各不相同。该应用程序可能想要聚合许多商品、想要该商品的客户、客户要求的商品类型和价格，并且可能有 70 种商品，其中 5 到 80 名客户平均每个请求 2 种类型的产品各1价。
取最极端的平均值，这可能会在一个完整的作业中产生 7000 个单独的（非常小的）数据请求。这是一个问题吗？可以将其打包一点，以便将客户类型和请求的价格捆绑在一起，但这仍然可能会同时出现几千个请求。
使用单个巨大的数据流会更好吗？或者几千个较小的？
I'm reviewing some code where we've had some issues with return data from a WCF web service. Currently the service makes a list of objects, serializes them (as JSON for the record) and returns the entire serialized list down the wire. Obviously when there's a lot of data users run into quota limit problems.
I'm considering changing it so the service returns one item at a time which would send a bunch of requests on a loop adding one object at a time into the list until it was done.
Obviously in scenario one we're making one request to the service that has the potential to return a massive amount of data and run up against the quota. In the other scenario we never hit the quota but the requesting app will be requesting data item after data item in a stream of separate requests.
To illustrate we have a list of items which come in a variety of item types and those types come at a variety of price points. The app might want to aggregate a number of items, the customers who want that item, the types of item and price requested by the customer and their could be maybe seventy items with between five and eighty customers each requesting on average 2 types of product at 1 price each.
Taking averages at the extreme end this could make 7000 separate (very small) data requests in a single complete job. Is that a problem? It is possible to package it up a bit so that customer types and prices requested could be bundled but that's still potentially a couple of thousand requests at one time.
Am I better off with a single huge data stream? Or a couple of thousand smaller ones?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您最好为您的场景提供最佳大小的回报:)这有点取决于请求的开销。一般来说，与 Web 服务之间的来回通信越少越好。
滑稽的答案，所以问题是：
您可能最好使用某种分页系统，其中您的请求要求特定数量的项目，并且您的响应在结果中返回“n of m”。这样您就可以调整请求数量和响应大小，以在您的情况下获得最佳性能。
You're better off with the optimal sized return for your scenario :) It kinda depends on the overhead on the request. Generally the less chatter back and forth to a web service the better.
Facetious answer, so here's the rub:
You're probably best off with some sort of paging system, wherein your request asks for a specific number of items, and your response returns a "n of m" in the results. That way you can tune the number of requests and size of the response to perform best in your situation.