就性能而言，拉取 json 数据的最佳方式是什么？
目前我正在使用 HttpWebRequest 从外部站点提取 json 数据，性能不佳。 wcf 更好吗？
我需要这方面的专家建议..
Currently I am using HttpWebRequest to pull json data from an external site, and the performance was not good. Is wcf much better?
I need expert advice on this..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能不是，但这不是正确的问题。
回答一下：WCF当然支持JSON，但最终会在底层使用HttpWebRequest，并且它肯定会具有相同的网络延迟。更重要的是，它将使用相同的服务器来获取 JSON。 WCF 在构建、维护和配置 Web 服务和客户端方面具有很多优势，但它的速度并不是神奇的。与 WCF 默认使用的方法相比，您的反序列化 JSON 的方法可能真的很慢，但我对此表示怀疑。
这就引出了真正重要的一点：找出性能不佳的原因。如果您知道什么是慢的，并且通过扩展，知道如何做不同的事情会降低速度，那么更改框架只是一个可以理解的优化选项。是服务器吗？是反序列化吗？是网络吗？是身份验证还是其他一些请求开销细节？等等。
所以真正的答案是：个人资料！一旦您了解性能问题的真正所在，您就可以就 WCF 这样的框架是否有帮助做出明智的决定。
Probably not, but that's not the right question.
To answer it: WCF, which certainly supports JSON, is ultimately going to use
HttpWebRequestat the bottom level, and it will certainly have the same network latency. Even more importantly, it will use the same server to get the JSON. WCF has a lot of advantages in building, maintaining, and configuring web services and clients, but it's not magically faster. It's possible that your method of deserializing JSON is really slow compared to what WCF would use by default, but I doubt it.And that brings up the really important point: find out why the performance is bad. Changing frameworks is only an intelligible optimization option if you know what's slow, and, by extension, how doing something different would make it less slow. Is it the server? Is it deserialization? Is it network? Is it authentication or some other request overhead detail? And so on.
So the real answer is: profile! Once you know what the performance issue really is, you can make an informed decision about whether a framework like WCF would help.
简短的回答是：不。
更长的答案是WCF是一个API，它不指定通信方法，但支持多种方法。但是，这些方法通常通过 SOAP 进行，这将比 JSON 涉及更多的偷听，并且 世界似乎已经决定放弃 SOAP。
您正在寻找什么样的表现以及您会得到什么？您可能只是面临网络位置的物理限制，在这种情况下，您可能会希望让您的界面感觉更具响应性，即使数据缓慢。
值得看看大部分延迟是否只是在到达远程站点时发生（例如，响应时间与 ping 时间相当）。或者，问题可能在于远程站点生成和提供页面所需的时间。如果是这样，一些中间缓存可能是最好的。
The short answer is: no.
The longer answer is that WCF is an API which doesn't specify a communication method, but supports multiple methods. However, those methods are normally over SOAP which is going to involve more overheard than a JSON, and it would seem the world has decided to move on from SOAP.
What sort of performance are you looking for and what are you getting? It may be that you are simply facing physical limitations of network locations, in which case you might look towards making your interface feel more responsive, even if the data is sluggish.
It'd be worth it to see if most of the latency is just in reaching the remote site (e.g. response times are comparable to ping times). Or, perhaps, the problem is the time it takes for the remote site to generate and serve the page. If so, some intermediate caching might be best.
对 Isaac 所说的+1，但我要补充的一件事是，如果您确实在这里使用 WCF，它会在大多数地方内部使用 HttpWebRequest，因此您绝对不会获得任何性能。然而，您可能无意中获得性能提升的一种方法是 WCF 如何在内部回收、重用、池化和缓存大多数传输对象。所以最终还是回到了 Isaac 关于分析的建议。
+1 on what Isaac said, but one thing I'd add is, if you do use WCF here, it'll internally use the HttpWebRequest in most places, so you're definitely not gaining performance at all. One way you may unintentionally gain in performance -- however -- is in how WCF recycles, reuses, pools, and caches most transport objects internally. So it ultimately goes back to Isaac's advice on profiling.