如何加速大型对象图的序列化和传输； WCF 3.5 和 WCF 3.5 SL3
我有一个 3.5 SP1 项目，WCF 服务仅限于 Silverlight 3 客户端使用。由于业务需求，我们必须使用大型对象图，这些对象图通过 WCF 端的 SQL Server 进行水合，然后发送到 Silverlight 客户端。它们很深，您可能有一个具有两个集合属性的类，并且集合中的每个项目内部都有集合。基本设计就是这样，是我继承的，并且必须在短期内工作。我们说的有多大？一个包含 250 个项目的顶级集合示例，在不使用任何修改（httpBinding 和 DataContractSerializer）的情况下通过网络进行序列化后，大小为 14mb。 250 个项目很小，我们面临的要求要求我们能够处理 10,000 多个项目，考虑到我有限的数学技能，要通过网络拉动的数据远远超过 500mb。不能在公园里散步——事实上——你可能可以在公园里散步，而这一切都在消失。
因此，我们正在考虑几件事，其中之一是放弃 DataContractSerializer 并使用 XmlSerializer，这样我们就可以将大量这些属性移至属性中并减少有效负载大小。我们还在研究二进制 Xml 绑定。
我的问题是，你会怎么做？ IIS 压缩可以在这里发挥作用吗？放弃 DCS 是一个坏主意吗？有更好的技术吗？我是在没有桨的情况下在小溪里吗？
I have a 3.5 SP1 project, WCF service which is limited to consumption by Silverlight 3 clients. Due to the business requirements we have to work with large object graphs that are hydrated via SQL Server on the WCF side and then sent to the Silverlight client. They are deep, you might have a class that has two collection properties and each item in the collection has collections inside of it. The fundamental design is what it is, something I inherited and must work within for the short term. How big are we talking? An example top level collection with 250 items once serialized is 14mb when coming across the wire using no modiciations (httpBinding and the DataContractSerializer). 250 items is small, the requirements we are facing require us to be able to work with 10,000+ items which given my limited math skills is well over 500mb to pull across the wire. No walk in the park - in fact - you could probably take a walk in the park while that churned away.
So there are several things we are considering, one is to move away from DataContractSerializer and use the XmlSerializer so we can move lots of these properties into attributes and reduce the payload size. We are also looking at Binary Xml bindings.
My question is this, what would you do? Can IIS compression play a role here? Moving away from the DCS a bad idea? Is there a better technique? Am I up a creek without a paddle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否绝对需要一次性提取所有数据？如果这是一个 Silverlight 应用程序，我看不到您实际显示您所描述的大小的 10,000 多个（甚至 250 条）记录。是否可以使用分页来减少通过线路拉取的数据量？
您可以每页显示 10-20 条记录，而不是 10,000 条以上，因此系统根据情况仅查询 10-20 条记录。
考虑到您描述的要求，不确定这是否适合您，但这对我来说似乎是最明显的解决方案。
另外，为了对您的性能有所帮助，您是否确保 正在为您的业务对象生成序列化程序集？这至少会优化代码的序列化/反序列化部分。这可能不会带来巨大的性能提升，但会有所帮助。
Do you absolutely need to pull down all of that data in one shot? If this is a Silverlight app, I can't see you physically displaying 10,000+ (or even 250 for that matter) records of the size you describe. Is it possible to use paging to reduce the amount of data pulled across the wire?
Instead of having 10,000+, you could be showing 10-20 records per page, so the system only queries 10-20 depending on the circumstances.
Not sure if that is an option for you, given the requirements you describe, but that seems to be the most obvious solution to me.
Also, to marginally help your performance, have you made sure serialization assemblies are being generated for your business objects? This would optimize at least the serialization/deserialization piece of your code. It may not be a huge performance boost, but it will help.
正如其他人所说，看看您是否需要传输这么多数据。
发送大量数据的最佳方法是使用流式传输，请参阅：
http: //msdn.microsoft.com/en-us/library/ms733742.aspx
As others have said, look if you need to transfer this amount of data.
The best way to send large amounts of data is to use streaming, see:
http://msdn.microsoft.com/en-us/library/ms733742.aspx