2

我有一个返回 JSON 数据的 WCF 服务。它必须能够返回 10000-50000 个对象。我已经做了一些计时，服务调用的方法主体完成所需的时间不到 10 毫秒，但客户端会延迟 5 秒或更长时间才能获得响应。出于开发目的，客户端和服务器都在同一台机器上，因此网络延迟不是一个因素。

我的感觉是，将 CLR 对象序列化为 JSON 是一直需要的。我考虑过对响应进行 GZiping，但我认为这实际上可能会使其变慢，因为网络带宽不是问题。我也考虑过使用 JSON.NET 而不是内置序列化，但我没有找到任何关于如何做到这一点的最新端到端信息，所以我无法让它工作，我'不确定它可以提供多少速度。

还有什么我应该考虑的以使这更快吗？

4

2 回答 2

2

使用开关值 All 启用跟踪。它应该揭示一些有用的东西。

<system.diagnostics>
 <sources>
  <source name="System.ServiceModel" switchValue="All" >
    <listeners>
      <add name="xml"
         type="System.Diagnostics.XmlWriterTraceListener"
         initializeData="C:\UserTraces.svclog" />
    </listeners>
  </source>
 </sources>
 <trace autoflush="true" />
</system.diagnostics>
于 2013-07-13T10:41:45.797 回答
0

我建议查看 vibhu 所说的跟踪，我不会太快排除网络带宽可能是瓶颈。根据我的经验，特别是对于大型消息，序列化开销和网络传输占整个操作响应时间的很大一部分。使用不同的绑定 - 例如命名管道。尝试在进程中调用服务。尝试将其中一条消息序列化到磁盘并将其反序列化回内存并在其周围包裹一个秒表计时器。这些是用于了解序列化成本的穷人工具。[dotTrace] 是一个高质量的商业分析器，它会告诉你很多关于时间花在哪里的信息。

最后，在我们的测试中，GZip 会提高您的 CPU 使用率，但对响应时间的影响很小，以换取明显更小的网络传输。最后，它对我们来说要快得多，我会向不受 CPU 限制的任何人推荐它。但是，如果您的问题是序列化成本而不是网络传输，那么这很可能无法解决您的直接问题。话虽如此，如果您的 CPU 有备用滴答声，这对于一般可扩展性来说可能只是一个好主意。

希望有帮助...

于 2013-07-15T00:41:34.170 回答