希望这不是太开放。我正在处理.NET 4, WPF, WCF, EF (STE's), SQL 2012申请。
我们受到客户的打击，因为当没有足够的可用带宽时，我们的应用程序会超时并挂在速度较慢的网络上。
我们的应用程序有一些“实时”仪表板式显示器以及一些基于网格的数据编辑器屏幕。
使用Fiddler，我仔细研究了产品中的不同功能区域 - 特别关注正在传输的数据量。简而言之，传输的数据太多 - 我们的一些WCF调用在一次调用中检索了超过100 MB的数据。
我相信我们所看到的问题可以通过以下事实来表征：在通过WCF和EF检索数据时，没有足够的谨慎，但也许我正在分析一些事情：
我非常喜欢可重复使用，但为什么要回复完全补水 当您需要的是一个id和一个选项列表的名称时，EF STE实体？ 有时，我们只需要一个简单的只读数据显示。为什么 序列化ChangeTracker信息，包括OriginalValues 收藏等？或许，值得将实体分成两部分 可编辑和“只读版本”或选项列表适当的版本？
现在，我们正在使用BasicHttpBinding / XML Serialization，但是 有效载荷似乎臃肿。例如，xml包含名称空间和a 一堆其他的噪音。启用IIS 7压缩有所帮助 大幅度地，但我们能做的更多吗？ JSON格式是一个 转移数据更好的选择？将XML更改为JSON就好了 虽然有重大改变。
是否还有其他技术可以用来缓解这种情况 有效负载大小 - 也许我们可以坚持使用XML序列化，但我们 只需要请求更少的数据。也许使用分页等技术 或“无限滚动”，延迟背景加载等等 好赌。
是否有其他人面临过无法接受的有效载荷大小？你做了什么来解决它？
谢谢！
答案 0 :(得分：1)
我认为你已经覆盖了大的那些。
尽可能使用DTO而不是完整实体（仅包含所需数据的简单数据类型）。您只需要一个简单的翻译课程 - 您甚至可以使用代码生成工具或AutoMapper之类的东西来帮助您。
使用NetTcpBinding而不是BasicHttpBinding - 这将显着减少消息大小，但是您将丢失HTTP / Fiddler调试，并且需要一些IIS配置。
或者如果你想坚持使用HTTP并使用JSON而不是XML，你将无法使用WCF BasicHttpBinding轻松完成，因为那是SOAP，但你可以转而尝试使用WebAPI。这对客户端和服务器来说都是一个重大变化。
那些应该减少你的尺寸相当多。从那里开始，继续探索以块的形式引入数据，或者使用大量的单个查询而不是一个大的查询。即使这些不会降低整体带宽，它们也能提供更好的用户体验。