流写入头文件花费太多时间 WCF

Question

类似的问题在NewRelic流和writeHeaders中被提出。

我正在使用New Relic对我的WCF服务进行性能分析。有一个WCF服务调用另一个WCF服务。 现在，我认为在调用另一个WCF服务时，在创建请求时，某些内部进程会将头写入请求流，这可能会导致缓慢。 我在New Relic中发现的跟踪结果告诉我，对于我的一个WCF服务的特定方法，该方法调用我的另一个WCF服务的方法，需要大约50-60秒，其中95-100％的时间由System.Net.ConnectStream.WriteHeaders消耗。

Stream[url of WCF service/soap]: WriteHeaders -> 99.78 % time (approx 49 seconds).

我不明白它是什么以及如何缩短这个时间?

我已经搜索过了，但我没有找到 ConnectStream 实际上做什么或者一些关于它的详细信息，因此我无法找到任何减少所需时间的方法。

请告诉我您的建议。

- Deeps

---

嗨@Deeps，你在这个问题上有什么好运吗？我们也面临着完全相同的问题。如果是的话，你能分享一下吗？谢谢。 - texens

嗨，texens，抱歉回复晚了。到目前为止，我还没有得到任何解决方案。 - Deeps

Answer 1

听起来你正在从客户端流式传输一个大文件，将其捕获在一个WCF Web服务中，然后将数据重新编写成一个新的HttpWebRequest，然后发送到另一个主机。我认为我会尝试缓冲来自客户端到您的Web服务的数据，而不是流式传输。

我过去一年一直在做一个类似于您正在做的项目。流式传输和缓冲之间的区别在于：

流式传输以迭代的方式读取（源）并写入（目标）数据，您无法对此进行太多控制。如果源文件很大（比如1GB或更多），则WCF请求/响应将在客户端和主机之间来回迭代十几次，直到请求完成。

另一方面，缓冲在填充请求并将其发送到主机之前积累目标文件的整个内容，从而加快了进程。由于缓冲所产生的性能惩罚（需要在内存中积累字节的时间）放在客户端上，因此通常不是问题。

因此，当从客户端缓冲数据时，您的主机将接收一个完整的字节数组（假设）的Http请求，该请求已准备好重新打包为传递到第二个目标WCF主机的请求。在那一点上，您再次可以选择缓冲或流式传输。在主机上，性能很重要时，将请求流式传输到第二个主机将提高可扩展性，但可能会损害性能速度。

在客户端方面：

    With binding
      .TransferMode =TransferMode.Buffered 'instead of Transfermode.Streamed                                                              
      .MessageEncoding = WSMessageEncoding.Text
      .TextEncoding = System.Text.Encoding.UTF8
      .MaxReceivedMessageSize = Integer.MaxValue
      .ReaderQuotas.MaxArrayLength = Integer.MaxValue
      .ReaderQuotas.MaxBytesPerRead = Integer.MaxValue
      .ReaderQuotas.MaxDepth = Integer.MaxValue
      .ReaderQuotas.MaxNameTableCharCount = Integer.MaxValue
      .ReaderQuotas.MaxStringContentLength = Integer.MaxValue
      .MaxBufferSize = Integer.MaxValue
      .MaxBufferPoolSize = Integer.MaxValue

在主机端：

With binding
      .TransferMode = TransferMode.Buffered
      .MaxReceivedMessageSize = Integer.MaxValue

- Brian

---

嗨，Brian，我没有在流式传输任何大文件或类似的东西。我只是请求一个WCF服务。我已经将一个WCF服务的服务引用添加到我的项目中，该项目也是一个WCF服务。现在我在我的服务中有一个方法GetMerchantData(string param1)，它从我的数据库中获取一些值，然后调用添加的服务引用的方法：GetMerchantStoreData(string param1, string param2, string param3)。请求看起来像这样： - Deeps

MyServiceRefClient客户端 = new MyServiceRefClient(); var result = client.GetMerchantStoreData(param1, param2, param3); 然后我从我的服务中返回这个结果。 这个结果对象包含12个属性。我认为它不是一个大数据，也不涉及任何流式传输。我认为它与在请求ssl托管的wcf服务时编写一些默认标头有关。但我无法弄清楚如何减少这个时间。因为我没有在我的代码中编写这行Stream[url of WCF service/soap]: WriteHeaders。谢谢。 - Deeps

我理解。很抱歉我无法提供更多帮助。 - Brian

Answer 2

当你调用的服务陷入停顿或被过多并发连接淹没时，我以前也见过同样的情况。如果问题是前者，对WCF服务进行分析可能有助于确定根本原因——也许由于数据库访问或其他I/O绑定进程而导致响应缓慢。如果问题是后者，可能可以通过调整服务的性能来解决（http://msdn.microsoft.com/en-us/library/ee377061(v=bts.10).aspx）。

这也可以表现为New Relic中ASP.NET应用程序的"BeginRequest"。很少有BeginRequest或WriteHeaders意味着问题真正出在发送数据本身上，尽管如果你有大量有效负载，它可能是如此，但在传输的数据较小的常规调用中，连接时间慢或响应缓慢的问题将出现在这两个区域。

- seanmcelroy