vb.net 第一次调用 .net 网络服务很慢

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/16086045/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-17 13:19:02  来源:igfitidea点击:

First call to a .net webservice is slow

c#vb.netweb-services.net-4.0asmx

提问by Brian M.

I'm calling a .net webservice from my .net winforms app, both in framework 4.0. During the execution of the program, the first time the webservice has a method called, the call takes ~10-12 seconds. Subsequent calls take ~1-2 seconds. Subsequent calls, even when the web reference instance is recreated, are still ~1-2 seconds. When the winforms app is restarted, the first call delay occurs again, but subsequent calls are responsive.

我正在从我的 .net winforms 应用程序调用 .net webservice,两者都在框架 4.0 中。在程序的执行过程中,webservice 第一次调用一个方法,调用需要~10-12 秒。后续调用大约需要 1-2 秒。后续调用,即使重新创建了 Web 引用实例,仍然需要大约 1-2 秒。当 winforms 应用程序重新启动时,再次发生第一次调用延迟,但后续调用是响应的。

The instance of the web reference is being created prior to the call occuring, and is not part of the delay.

Web 引用的实例是在调用发生之前创建的,并且不是延迟的一部分。

XmlSerializers for the winforms app are being generated (and used, as far as I know, but I'm not sure how to verify this).

winforms 应用程序的 XmlSerializers 正在生成(并使用,据我所知,但我不确定如何验证这一点)。

The delay is not occuring because of a first-run compilation on the webservice side. This is a production webservice that is being used throughout the day, and its apppool is remaining in memory. As far as I can see, the delay is occurring either on the client side, or between the client and the server for that first call, but not subsequent calls.

由于 Web 服务端的首次运行编译,不会发生延迟。这是一个全天都在使用的生产网络服务,它的应用程序池保留在内存中。据我所知,延迟发生在客户端,或客户端和服务器之间的第一次调用,但不是后续调用。

Not sure what to check next. Any ideas?

不知道接下来要检查什么。有任何想法吗?

回答by Brian M.

As spenderhad indicated, the issue had to do with the proxy detection. Turning that off in Internet Explorer solved the problem, but was not feasible to do in my situation.

正如支出者所指出的,问题与代理检测有关。在 Internet Explorer 中关闭它解决了问题,但在我的情况下不可行。

Instead, there is a workaround to bypass the use of the default proxy, and therefore the automatic detection.

相反,有一种解决方法可以绕过默认代理的使用,从而绕过自动检测。

Adding these entries to the app.config allows certain URLs to bypass the proxy:

将这些条目添加到 app.config 允许某些 URL 绕过代理:

<configuration>
    <system.net>
        <defaultProxy>
            <bypasslist>
                <add address="server/domain name" />
            </bypasslist>
        </defaultProxy>
    </system.net>
</configuration>

More information can be found here: <defaultProxy Element> on MSDN

更多信息可以在这里找到:<defaultProxy Element> on MSDN

回答by Prash

try setting the proxy to an empty WebProxy, ie:

尝试将代理设置为空的 WebProxy,即:

request.Proxy = new WebProxy(); 

or you can override the proxy settings in the .Config file for your application using the defaultProxy key in the system.net section. The following disables automatic Proxy detection:

或者,您可以使用 system.net 部分中的 defaultProxy 键为您的应用程序覆盖 .Config 文件中的代理设置。以下禁用自动代理检测:

<configuration >
  <system.net>
    <defaultProxy>
      <proxy bypassonlocal="true" usesystemdefault="false" />
    </defaultProxy>
</system.net>
</configuration>

http://weblog.west-wind.com/posts/2005/Dec/14/Slow-Http-client-calls-from-ASPNET-20-Make-sure-you-check-your-Proxy-Settings

http://weblog.west-wind.com/posts/2005/Dec/14/Slow-Http-client-calls-from-ASPNET-20-Make-sure-you-check-your-Proxy-Settings

回答by Kevin

Apologize for the necro-add, but this issue has come up a number of times for me, and I have a habit of forgetting all the aspects of this issue each time. So here's the list (some of which other people mentioned)

为 necro-add 道歉,但是这个问题对我来说已经出现了很多次,而且我有一个习惯,每次都忘记这个问题的所有方面。所以这是列表(其他人提到的一些)

  • Change your System.ServiceModel.BasicHttpBinding so that the BypassProxyOnLocal and UseDefaultWebProxy are both false. (You can decide whether you want to do this in a config file or via code.)
  • Change the ‘Generate Serialization Assembly' in the projects ‘Build' properties to ‘On' instead of ‘Auto'
  • Make sure you're using a modern .NET framework. 4.6.1 is about 60 MS faster than 4.5.2 on the first request, for instance.
  • Do your performance testing on a Release Executable, not within VisualStudio (VS adds a large additional overhead on the initial call that is notreflected in the actual release .exe build.)
  • If you're working with a service/site that continually run, definitely consider sending a dummy request to the server upon startup - simply to get .NET to serialize the connection up front. Likewise, if you're writing a run-and-quit app, consider writing a background dummy request while the program is starting up.
  • Make sure the service you're connecting to doesn't recycle very often. Every time the app pool recycles on an IIS service, the first request coming in after recycle can take awhile.
  • Make sure the service you're connecting to doesn't hibernate. By default, a service hibernates after 20 minutes of inactivity - and the next request that comes in has a delay similar to a post-recycle request.
  • 更改您的 System.ServiceModel.BasicHttpBinding,使 BypassProxyOnLocal 和 UseDefaultWebProxy 都为 false。(您可以决定是在配置文件中还是通过代码执行此操作。)
  • 将项目“构建”属性中的“生成序列化程序集”更改为“开”而不是“自动”
  • 确保您使用的是现代 .NET 框架。例如,4.6.1 在第一次请求时比 4.5.2 快 60 MS。
  • 在 Release Executable 上进行性能测试,而不是在 VisualStudio 中进行(VS 在初始调用上增加了大量额外开销,而这些开销并未反映在实际发布 .exe 版本中。)
  • 如果您正在使用持续运行的服务/站点,请务必考虑在启动时向服务器发送一个虚拟请求 - 只是为了让 .NET 预先序列化连接。同样,如果您正在编写一个运行并退出的应用程序,请考虑在程序启动时编写一个后台虚拟请求。
  • 确保您连接的服务不会经常回收。每次应用程序池在 IIS 服务上回收时,回收后进入的第一个请求可能需要一段时间。
  • 确保您要连接的服务不会休眠。默认情况下,服务在 20 分钟不活动后休眠 - 下一个请求的延迟类似于回收后请求。

回答by Bertie

I have suffered this problem many times - man I hate it!!! lol Whilst I have never conclusively solved it, you could try a couple of things. Firstly, make a call to the web service during start up and get the 'pain' out of the way first! Secondly, try messing with the web service's IIS application pool - make it so that it never recycles itself or at least does so at an un-Godly hour of the morning or perhaps per 10000 requests.

我已经多次遇到这个问题 - 我讨厌它!大声笑虽然我从来没有最终解决它,你可以尝试一些事情。首先,在启动过程中调用 Web 服务并首先消除“痛苦”!其次,尝试弄乱 Web 服务的 IIS 应用程序池 - 使其永远不会自行回收,或者至少在早晨的非神圣时刻或每 10000 个请求中这样做。

I know this probably isn't that great an answer, but hope it helps a little!

我知道这可能不是一个很好的答案,但希望它会有所帮助!



EDIT :

编辑 :

Part of the issue is that the web service isn't 'always' up - it goes to sleep, recycles etc until needed. It would be worth reading up on keeping web-services alive, 5 9s up time etc!

部分问题在于 Web 服务并非“始终”启动——它会进入休眠、回收等状态,直到需要为止。值得一读关于保持网络服务的活力,5 个 9 的正常运行时间等!

回答by Paolo Marani

I've added these settings on my basicHttpBinding, disabling the automatic proxy detection and gaining a great speedup on first execution time. This of course works well if you are into intranet environment, or you know you do not need any proxy at all.

我已经在我的basicHttpBinding上添加了这些设置,禁用了自动代理检测并在第一次执行时获得了很大的加速。如果您进入 Intranet 环境,或者您知道根本不需要任何代理,这当然很有效。

bypassProxyOnLocal="false"

绕过代理OnLocal =“假”

useDefaultWebProxy="false"

useDefaultWebProxy="false"

Hope this helps.

希望这可以帮助。