Question

我们有一个.NET 3.5应用程序，用于调用服务器上的Web服务。在这个应用程序的几乎每个安装中，整个请求/回复过程大约需要半秒钟。

在一个特定的装置中，这些请求神秘地花费了大约85秒（半秒钟内）。

我的第一个想法是webservice客户端每次调用都在重建XML序列化程序集，但即使直接发送硬编码的xml文件仍然几乎完全相同的时间。观察网络流量似乎表明交易的实际发送数据部分发生在一秒钟之内。所以问题全在客户端。

是否存在可能导致此问题的某种权限延迟？

编辑（更多细节）：
该应用程序是Web服务查询的基本包装器 - 键入一些参数，将查询发送到Web服务并获得响应。我们从wsdl.exe工具生成的客户端代码开始，但在遇到问题时也尝试直接使用HttpWebRequest。从跟踪日志和网络跟踪开始，流程似乎是：

T 0:00 - user initiates request
T 1:24 - the application sends request to server
T 1:25 - the client receives the response and displays to the user.

Answer 1

感谢您的所有建议。问题是由代理自动检测引起的。基本上，如果将Internet Explorer设置为自动检测代理，那么HttpWebRequest也会在每次创建新的WebRequest时自动检测，而不是以有用的方式缓存任何内容。

最终，我发现了这篇知识库文章：http://support.microsoft.com/kb/968699

解决方案只是将其添加到app.config文件中：

<configuration>
    <system.net>
        <defaultProxy >
            <!-- Disable Autoproxy-->
            <proxy autoDetect="false"/>
        </defaultProxy>
    </system.net>
</configuration>

Answer 2

如果数据在一秒钟内发送但总响应时间为85秒，为什么您觉得问题出在客户端？从服务器收到回复需要85秒吗？

通常，如果您看到非常一致（半秒内）延迟的类型，请在处理过程中查找某种超时。这听起来非常像网络超时。是否存在服务器可能尝试访问的网络资源？身份验证就是这样一种网络资源文件共享，外部http或ftp调用也可以是候选者。

您能更详细地描述一下您的申请吗？

Answer 3

听起来像是超时问题。有人想过 - 配置了什么类型的代理？机器在执行请求之前是否尝试检测HTTP代理？我认为是时候使用网络监视器来查看发生了什么。

Answer 4

如果该服务也是.NET，您可以使用跟踪查明问题的根源。您可以按如下方式向web.config添加跟踪：

 <system.diagnostics>
        <sources>
            <source name="System.ServiceModel"
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
                <listeners>
                    <add name="traceListener"
                        type="System.Diagnostics.TextWriterTraceListener"
                        initializeData="c:\temp\Traces.txt"  />
                </listeners>
            </source>
        </sources>
    </system.diagnostics>

这将跟踪'System.ServiceModel'的任何活动，它是3.5

中的webservices

Answer 5

在执行请求时，使用wireshark等程序嗅探网络。首先在客户端，如果你仍然在服务器的黑暗中。（两者同时提供更多洞察力）。

这样你可以排除，tcp-ip重传，身份验证问题，代理怪异等等

什么可能导致拨打网络服务两分钟的延迟？

5 个答案: