希望这不是太开放。我正在处理.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。这对客户端和服务器来说都是一个重大变化。
那些应该减少你的尺寸相当多。从那里开始,继续探索以块的形式引入数据,或者使用大量的单个查询而不是一个大的查询。即使这些不会降低整体带宽,它们也能提供更好的用户体验。