Question

我在一个IIS应用程序中运行了一堆.NET Webservices。这些Web服务由另一个IIS应用程序（前端）使用。第一个电话很慢，大概5到10秒。在那之后它只是几毫秒。第一个电话被认为是性能问题。

我们尝试过调用所有这些Web服务的应用程序，但这显然无法解决任何问题。因此，问题不在于默认的应用程序回收。我创建了一个应用程序，它只是多次初始化服务并测量创建一个实例所需的时间。在运行此应用程序之前，我确保启动/回收我的Web服务应用程序，然后运行该应用程序。第一次初始化需要2到4秒，其他所有其他只需几毫秒。

另一个想法是我们在前端应用程序中创建一个页面来启动所有的Web服务，并且我们在任何用户进入之前调用此页面。我不认为这是一个优雅的解决方案，我还能尝试什么？

Answer 1

客户端第一次调用Web服务时遇到的延迟是由于默认情况下需要编译Web服务的XmlSerializers dll。这导致初始呼叫的2-4秒。当然，当webservice应用程序已经运行时就是这种情况，如果它不是你将有一个回收。在这种情况下，其他答案可能有所帮助。

要加快初始调用，可以在编译时创建XmlSerializers dll。您可以通过将项目构建“生成序列化程序集”设置为打开来执行此操作。这将生成包含Web服务信息的MyApplication.XmlSerializers.dll。现在，初始调用降至300毫秒，可能是dll的加载。之后的所有呼叫都需要0 ms。

在Visual Studio中右键单击您的项目，然后选择“属性”。转到“构建”选项卡。您可以在“输出”部分中选择“生成序列化程序集”。如果将值更改为“On”，则将在编译期间生成序列化程序集。

Answer 2

第一次调用Web服务时，或者在长时间延迟后第一次启动Web服务时，需要启动。这是你看到延迟的地方。在那之后，它已经开始并且会对呼叫做出快速响应。这是标准的Web服务行为。

您可以将IIS配置为keepalive = true - 这可以提高性能。

根据要求提供更多信息。

可能是在运行时创建序列化程序集。您可以使用项目属性窗口的“构建”窗格底部的下拉列表来更改序列化程序集的设置。

可能是您编写了Web服务以在应用程序启动时执行大量操作，这将在第一次调用服务上的方法时发生。

可能是操作非常慢，但是您正在缓存响应，这会使后续调用更快。

Answer 3

我最近发现在我们的ASMX文件中我们只引用了类名。我们在每个ASMX文件的不同程序集中获得了服务实现。这会导致.NET框架扫描整个bin文件夹，查找包含实现的程序集。随着您的Web服务应用程序的增长，这将消耗更多时间。这可以通过不仅在ASMX定义中包含类名而且还包括程序集名称来解决。

我们的ASMX看起来像这样：

<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice” %>

如果更改它以包含包含实现的程序集，它将如下所示。这节省了我们初始加载Web服务应用程序的10％左右。

<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice, MyWebservice.Implementation.Assembly” %>

Answer 4

这是典型的，因为ASP.NET应用程序会在第一次请求时编译并将bin \目录加载到内存中。

首先要做的事情：

删除bin目录中所有不必要的dll。（我见过人们运送nunit.dll）

预编译ASP.NET应用程序，以便IIS不需要。请参阅“VS 2008 Web Deployment Project Support Released”

Answer 5

不确定这是否会在“第一次”解决WS的慢速旋转，因为我认为有一堆编译和.net DLL被加载，但你几乎可以通过确保消除任何未来的冷启动WS所在的应用程序池配置正确。

默认情况下，IIS6在空闲时“重新生成”，经过几分钟或“循环”事件，每次都有效地重启WS。如果您对此服务感到满意，那么就不需要这些服务。

确保WS拥有自己的专用应用程序池（不共享不合适的池）也是一个强烈的建议。

Answer 6

经过几个小时的疯狂测试，我已经能够将webservice的首次执行时间减少到相同IP级别（低于300毫秒）的两台主机的最低限度....

我在第一次网络服务呼叫时首先经历了2-3秒的初始延迟，而不是来自同一进程的任何后续呼叫都非常快。

理解我案例延迟的关键是客户端如何处理WEB PROXY !!

这是我在app.config文件中的新绑定：

  <basicHttpBinding>
    <binding name="CreateContextSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
        receiveTimeout="01:00:00" sendTimeout="01:00:00" allowCookies="false"
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
        maxBufferSize="16777216" maxBufferPoolSize="524288" maxReceivedMessageSize="16777216"
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
        useDefaultWebProxy="false">
      <readerQuotas maxDepth="32" maxStringContentLength="1048576" maxArrayLength="16384"
          maxBytesPerRead="65536" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
            realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>

我认为第一次网络电子邮件执行速度要慢得多，因为传输通道需要在初始化时发现代理配置，以便透明地连接到互联网。内部网环境通常不需要这样做，因此我更改了这些绑定设置以避免使用默认代理（从资源管理器设置中自动发现）：

<强> bypassProxyOnLocal = “假”

<强> useDefaultWebProxy = “假”

首次呼叫连接时间现在减少了很多。希望这会有所帮助。

Answer 7

对于necro添加很抱歉，但这对我来说也是一直在进行的斗争，我想在图片中添加一些信息。 VisualStudio本身在时间上增加了一个相当大的组件。这是基本测试，涉及一个简单的表单应用程序和一个已在公司服务器上内部托管的Web服务（对于所有测试，Generate Serialization Assembly设置为true）：

Running in VS, Debug:
    First Call: 400 ms to set up client object, 450 to call function
    Second Call: 1 ms to set up client object, 14 to call function
Running as .exe, Release:
    First Call: 20 ms to set up client object, 70 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running the Debug's .exe file outside of vs:
    First Call: 20 ms to set up client object, 80 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running as Release within VS:
    Similar results to Debug in VS -- very slow

短篇小说？ Visual Studio为图片添加了大量时间。而不是~90毫秒，它花了将近一秒钟。因此，如果您正在进行性能调整，请确保在VisualStudio环境之外进行测试。

ASMX Web服务请求缓慢

7 个答案: