0

希望这不是太开放。我正在开发一个.NET 4, WPF, WCF, EF (STE's), SQL 2012应用程序。

我们受到客户的抨击，因为我们的应用程序在没有太多可用带宽的情况下超时并挂在较慢的网络上。

我们的应用程序有一些类似“实时”仪表板的显示以及一些基于网格的数据编辑器屏幕。

使用 Fiddler，我仔细研究了产品中的不同功能区域 - 特别关注正在传输的数据量。简而言之，传输的数据太多了——我们的一些 WCF 调用在一次调用中检索了超过 100 MB 的数据。

我相信我们所看到的问题可以通过以下事实来描述：通过 WCF 和 EF 检索数据时根本没有采取足够的措施，但也许我过度分析了：

  • 我是可重用性的忠实拥护者，但是当您只需要一个 id 和一个选项列表的名称时，为什么要返回一个完全水合的 EF STE 实体呢？有时，我们只需要对数据进行简单的只读显示。为什么要序列化包括 OriginalValues 集合等的 ChangeTracker 信息？也许，值得将实体拆分为可编辑和“只读版本”或选择列表适当的版本？

  • 现在，我们正在使用 BasicHttpBinding/XML 序列化，但有效负载似乎臃肿。例如，xml 包含名称空间和一堆其他噪音。启用 IIS 7 压缩有很大帮助，但我们还能做更多吗？JSON 格式会是传输数据的更好选择吗？不过，将 XML 更改为 JSON 似乎是一项重大变化。

  • 是否有任何其他技术可用于减轻有效负载大小 - 也许我们可以坚持使用 XML 序列化，但我们只需要请求更少的数据。也许使用分页或“无限滚动”、延迟背景加载等技术将是一个不错的选择。

有没有其他人面临过大到无法接受的有效载荷大小？你做了什么来解决它？

谢谢！

4

1 回答 1

1

我想你已经涵盖了大的。

尽可能使用 DTO 而不是完整实体（仅包含您需要的数据的简单数据类型）。您只需要一个简单的翻译类 - 您甚至可以使用代码生成工具或 AutoMapper 之类的工具来帮助您。

使用 NetTcpBinding 而不是 BasicHttpBinding - 这将显着减少消息大小，但您将失去 HTTP/Fiddler 调试，并且需要一些 IIS 配置。

或者，如果您想坚持使用 HTTP 并使用 JSON 而不是 XML，您将无法使用 WCF BasicHttpBinding 轻松做到这一点，因为那是 SOAP，但您可以换档尝试 WebAPI。不过，这对客户端和服务器来说都是一个重大变化。

那些应该把你的尺寸缩小很多。从那里开始，继续探索以块的形式引入数据，或者使用大量单独的查询而不是一个大查询。即使这些不会降低整体带宽，它们也会提供更好的用户体验。

于 2013-05-28T18:45:53.680 回答