C# WCF客户端挂起响应

我有一个指向WebSphere服务的WCF客户端（在Win7上运行）

通过测试工具（我的web应用程序外的一个小测试夹具）一切都很好，但是当我对服务的调用来自我的web项目时，其中一个调用（并且只有那一个）反序列化速度非常慢（需要几分钟VS几秒钟），而且不仅仅是第一次

我可以从fiddler中看到，响应很快就会返回，但随后WCF客户端在调试器命中下一行代码之前会将响应本身挂起一分钟以上，这几乎是在客户端反序列化遇到问题的情况下。只有在响应中有一个给定的pdf字符串（该操作生成一个pdf），并且是base64编码的分块时，才会发生这种情况。例如，如果服务引发错误（因此pdf字符串不存在），则响应将立即反序列化

同样，如果我通过soapui或从web项目外部发送完全相同的信封，一切都很好

我不知所措-我应该寻找什么，是否有一些配置设置可以做到这一点

感谢您的帮助

编辑：

---

我根据同一份服务合同编写了一个存根。使用完全相同的basicHttpBinding并返回完全相同的pdf字符串，不会注册延迟。我认为这排除了字符串和绑定可能的原因。还剩下什么？

这东西咬了我很多次。在WCF客户端配置中检查您是否未尝试使用windows web代理，检查代理的步骤（即使未配置代理）将在连接过程中占用大量时间。

首先要检查的事项：

• web项目和测试项目中的配置是否相同
• 当您从soapui进行测试时，您是在相同的服务器和安全上下文中进行测试的，就像代码从web项目运行时一样。 -当pdf返回时，内存中是否有峰值

编辑

从您的评论来看，等待1分钟似乎是在等待超时。你还提到了交易

我想知道问题是否出在别的地方。对WCF服务的调用正常，但调用在事务内部，并且事务上没有完成或处置（我在这里猜测），那么事务/代码将在等待超时时挂起1分钟

编辑2

接下来要检查的事项：

• 在测试代码和web项目中，在如何调用服务方面有什么不同吗
• 框架版本有什么不同吗，例如一个是3.0，另一个是3.5

---

如果其他用户的提示没有帮助，您可能希望在中打开它。这些信息很详细，但它使我能够修复过去一些难以识别的问题

---

可以找到有关WCF跟踪的更多信息。

是否客户端正在尝试分析来自服务器端的内容类型？尝试在服务器端明确指定服务响应的mime类型，例如

response.ContentType=“application/pdf”

EDIT：在客户端，我指的是任何可能的中介，如防火墙或安全套件。

您可以尝试两件事：

调整客户端的readerQoutas设置。看

在调试选项中禁用“仅我的代码”。工具->选项->调试->常规“仅启用我的代码（仅限托管）”并查看是否可以捕获内部WCF异常

---

//huusom将绑定上的

transferMode=“Buffered”

更改为

transferMode=“Streamed”

，成功了

因此，有效载荷显然被分块成了缓冲区大小的小块

---

我原以为通过增加buffersize（

maxBufferSize=“1000000”

）也可以实现同样的效果，但我已经准备好了，而且没有任何帮助。

我也遇到了同样的问题。。。WCF IMO的问题在于将服务返回的base64字符串反序列化为byte[]客户端

如果您可能不更改服务配置（例如：使用transferMode=“Streamed”），则最容易解决此问题的方法是调整DataContract/ServiceContract客户端。将响应DataContract中的类型“byte[]”替换为“string”

接下来，您只需自己用一段代码解码返回的字符串，如：

字节[]文件=Convert.FromBase64String（pdfBase64String）

要下载70KB的PDF文件，通常需要约6秒。根据上面建议的更改，现在需要<1秒

五,

---

注：关于传输模式，我尝试只更改客户端（transferMode=“streamdresponse”），但没有改进…

thx！如何做到这一点？是否需要检查任何特定设置？useDefaultWebProxy=“false”不好-仍在发生-任何其他建议？抱歉，当我将我的设置从true更改为false时，它解决了我的速度问题。thx-binding+endpoint完全相同，服务引用也完全相同。我在同一台机器上，在同一个上下文中进行所有测试。唯一不同的是，这只发生在web项目中。未检查内存-将尝试检查并查找峰值。一件有趣的事情是，即使我看到响应立即返回fiddler，WCF跟踪在反序列化完成后记录请求/响应对-1分钟后（它显示事务完成所用的时间超过1分钟）很抱歉造成混淆-不涉及此类交易。我所说的事务是指请求/响应对。到目前为止，我认为问题在于pdf字符串是base64编码的。请参阅我对该问题的最后一次编辑-我认为可以排除字符串的编码（事实上，作为原因没有意义）调用服务的方式没有区别（通过