ASP。IIS7上的NET应用程序——iisreset后启动非常缓慢

时间:2022-09-11 15:03:02

I have an ASP.NET 3.5 website running under IIS7 on Windows 2008.

我有一个ASP。NET 3.5运行在Windows 2008 IIS7下的网站。

When I restart IIS (iisreset), then hit a page, the initial startup is really slow.

当我重新启动IIS (iisreset)时,点击一个页面,初始启动会很慢。

I see the following activity in Process Explorer:

我在Process Explorer中看到以下活动:

  • w3wp.exe spawns, but shows 0% CPU activity for about 60 seconds
  • w3wp。exe生成,但在大约60秒内显示0%的CPU活动
  • Finally, w3wp.exe goes to 50% CPU for about 5 seconds and then the page loads.
  • 最后,w3wp。exe在大约5秒内达到50% CPU,然后页面加载。

I don't see any other processes using CPU during this time either. It basically just hangs.

在此期间我也没有看到任何其他进程使用CPU。它基本上只是挂。

What's going on during all that time? How can I track down what is taking all this time?

这段时间发生了什么?我怎么能找到这些时间里发生了什么?

6 个解决方案

#1


6  

We had a similar problem and it turned out to be Windows timing out checking for the revocation of signing certificates. Check to see if your server is trying to call out somewhere (e.g. crl.microsoft.com). Perhaps you have a proxy setting incorrect? Or a firewall in the way? We ultimately determined we had enough control over the server and did not want to 'call home', so we simply disabled the check. You can do this with .NET 2.0 SP1 and later by adding the following to the machine.config.

我们也遇到过类似的问题,结果是Windows超时检查撤销签名证书。检查您的服务器是否试图在某个地方呼叫(例如crl.microsoft.com)。也许您的代理设置不正确?或者是防火墙?我们最终决定对服务器有足够的控制权,不想“打电话回家”,所以我们只是禁用了支票。您可以使用. net 2.0 SP1来实现这一点,稍后将以下内容添加到machine.config中。

<runtime> <generatePublisherEvidence enabled="false"/> </runtime>

I am not sure if you can just put this in your app.config/web.config.

我不确定你是否可以把这个放到你的app.config/web.config中。

#2


4  

IL is being converted into machine native code (Assembly) by the Just-In-Time compiler and you get to wait while all the magic happens.

IL正在被即时编译器转换为机器本机代码(Assembly),当所有神奇的事情发生时,您可以等待。

When compiling the source code to managed code, the compiler translates the source into Microsoft intermediate language (MSIL). This is a CPU-independent set of instructions that can efficiently be converted to native code. Microsoft intermediate language (MSIL) is a translation used as the output of a number of compilers. It is the input to a just-in-time (JIT) compiler. The Common Language Runtime includes a JIT compiler for the conversion of MSIL to native code.

编译源代码到托管代码时,编译器将源代码转换为Microsoft中间语言(MSIL)。这是一组独立于cpu的指令集,可以有效地转换为本机代码。Microsoft中间语言(MSIL)是一种翻译,用作许多编译器的输出。它是即时(JIT)编译器的输入。公共语言运行时包括一个JIT编译器,用于将MSIL转换为本机代码。

Before Microsoft Intermediate Language (MSIL) can be executed it, must be converted by the .NET Framework just-in-time (JIT) compiler to native code. This is CPU-specific code that runs on the same computer architecture as the JIT compiler. Rather than using time and memory to convert all of the MSIL in a portable executable (PE) file to native code. It converts the MSIL as needed whilst executing, then caches the resulting native code so its accessible for any subsequent calls.

在Microsoft中间语言(MSIL)可以被执行之前,必须将. net框架即时(JIT)编译器转换为本地代码。这是特定于cpu的代码,运行在与JIT编译器相同的计算机架构上。而不是使用时间和内存将可移植可执行文件中的所有MSIL转换为本机代码。它在执行时将MSIL转换为需要,然后缓存生成的本地代码,以便以后的任何调用都可以访问。

source

#3


4  

Thats the compilation of asp.Net pages into intermediate language + JIT compilation - it only happens the first time the page is loaded. (See http://msdn.microsoft.com/en-us/library/ms366723.aspx)

这就是asp的汇编。将网页转换为中级语言+ JIT编译—只在第一次加载页面时发生。(参见http://msdn.microsoft.com/en-us/library/ms366723.aspx)

If it really bothers you then you can stop it from happening by pre-compiling your site.

如果它真的困扰你,那么你可以通过预编译你的站点来阻止它的发生。

EDIT: Just re-read the question - 60 seconds is very long, and you would expect to see some processor activity during that time. Check the EventLog for errors / messages in the System and Application destinations. Also try creating a crash dump of the w3wp process during this 60 seconds - there is an chance you might recognise what its doing by looking at some of the call stacks.

编辑:只要重新阅读这个问题——60秒是很长的一段时间,你将会看到一些处理器的活动。检查EventLog以查找系统和应用程序目的地中的错误/消息。也可以尝试在这60秒内创建w3wp进程的崩溃转储——通过查看一些调用堆栈,您可能会发现它在做什么。

If it takes exactly 60 seconds each time then its likely that its waiting for something to time out - 60 seconds is a nice round number. Make sure that it has proper connections to the domain controllers etc...

如果每次都要花60秒,那么它很可能在等待某物超时——60秒是一个很好的整数。确保它与域控制器等有适当的连接。

(If there are some IIS diagnostic tools that would do a better job then I'm afraid I'm not aware of them, this question might be more suited to ServerFault, the above is a much more developer-ish approach to troubleshooting :-p)

(如果有一些IIS诊断工具可以做得更好,那么我恐怕我没有意识到它们,这个问题可能更适合于服务器故障,上面是一个更加开发的解决方法:-p)

#4


4  

I found that there was a network delay making an initial connection from the front end web server to the database server.

我发现存在一个网络延迟,导致从前端web服务器到数据库服务器的初始连接。

The issue was peculiar to Windows 2008 and our specific network hardware.

这个问题是Windows 2008和我们的特定网络硬件所特有的。

The resolution was to disable the following on the web servers:

决议是在web服务器上禁用以下内容:

#5


2  

Greater than 60 seconds sounds fishy. Try running a test.html page to see how long that takes. That will isolate IIS7's role.

超过60秒听起来很可疑。尝试运行一个测试。看看需要多长时间。这将孤立IIS7的作用。

Then temporarily rename your web.config, global.asax and application folders and try a test.aspx page (very simple page). That will isolate ASP.NET.

然后暂时重命名您的web。配置,全球。asax和应用程序文件夹并尝试一个测试。aspx页面(非常简单的页面)。将隔离ASP.NET。

If both of those are fast (i.e. about 10 seconds), then it's your application. But, if either are slow then not the application and something with the server itself.

如果两者都是快速的(即大约10秒),那么这就是你的应用程序。但是,如果两者都很慢,那么不是应用程序和服务器本身。

#6


1  

This hat nothing to do with JIT compiling. The normal C# compiler compiles your code behind files (.aspx.cs) into intermediate language into an assembly at startup if this assembly dont exist or code files have changed. Your web site assembly is located in the "bin" folder of your web site.

这与JIT编译无关。正常的c#编译器将您的代码在文件(.aspx.cs)中编译成中间语言,如果这个程序集不存在,或者代码文件发生了变化,那么在启动程序中就会生成一个程序集。您的web站点组装位于web站点的“bin”文件夹中。

In fact the JIT compiling occures after that, but this is very fast and won't take several minutes. JIT Compiling happens on every startup of an .net application and that won't take more than a view seconds.

实际上,JIT编译发生在这之后,但是这非常快,不会花几分钟的时间。JIT编译发生在。net应用程序的每一次启动上,这只需要几秒钟的时间。

You can avoid the copmpiling of your web site if you deploy the already compiled website assembly (YourWebsite.dll) into the bin folder. It is also possible to deploy only the aspx files and leave the code behind files (aspx.cs) files away.

如果将已经编译好的网站程序集(YourWebsite.dll)部署到bin文件夹中,就可以避免web站点的复制。也可以只部署aspx文件并将代码留在文件(aspx.cs)文件之外。

#1


6  

We had a similar problem and it turned out to be Windows timing out checking for the revocation of signing certificates. Check to see if your server is trying to call out somewhere (e.g. crl.microsoft.com). Perhaps you have a proxy setting incorrect? Or a firewall in the way? We ultimately determined we had enough control over the server and did not want to 'call home', so we simply disabled the check. You can do this with .NET 2.0 SP1 and later by adding the following to the machine.config.

我们也遇到过类似的问题,结果是Windows超时检查撤销签名证书。检查您的服务器是否试图在某个地方呼叫(例如crl.microsoft.com)。也许您的代理设置不正确?或者是防火墙?我们最终决定对服务器有足够的控制权,不想“打电话回家”,所以我们只是禁用了支票。您可以使用. net 2.0 SP1来实现这一点,稍后将以下内容添加到machine.config中。

<runtime> <generatePublisherEvidence enabled="false"/> </runtime>

I am not sure if you can just put this in your app.config/web.config.

我不确定你是否可以把这个放到你的app.config/web.config中。

#2


4  

IL is being converted into machine native code (Assembly) by the Just-In-Time compiler and you get to wait while all the magic happens.

IL正在被即时编译器转换为机器本机代码(Assembly),当所有神奇的事情发生时,您可以等待。

When compiling the source code to managed code, the compiler translates the source into Microsoft intermediate language (MSIL). This is a CPU-independent set of instructions that can efficiently be converted to native code. Microsoft intermediate language (MSIL) is a translation used as the output of a number of compilers. It is the input to a just-in-time (JIT) compiler. The Common Language Runtime includes a JIT compiler for the conversion of MSIL to native code.

编译源代码到托管代码时,编译器将源代码转换为Microsoft中间语言(MSIL)。这是一组独立于cpu的指令集,可以有效地转换为本机代码。Microsoft中间语言(MSIL)是一种翻译,用作许多编译器的输出。它是即时(JIT)编译器的输入。公共语言运行时包括一个JIT编译器,用于将MSIL转换为本机代码。

Before Microsoft Intermediate Language (MSIL) can be executed it, must be converted by the .NET Framework just-in-time (JIT) compiler to native code. This is CPU-specific code that runs on the same computer architecture as the JIT compiler. Rather than using time and memory to convert all of the MSIL in a portable executable (PE) file to native code. It converts the MSIL as needed whilst executing, then caches the resulting native code so its accessible for any subsequent calls.

在Microsoft中间语言(MSIL)可以被执行之前,必须将. net框架即时(JIT)编译器转换为本地代码。这是特定于cpu的代码,运行在与JIT编译器相同的计算机架构上。而不是使用时间和内存将可移植可执行文件中的所有MSIL转换为本机代码。它在执行时将MSIL转换为需要,然后缓存生成的本地代码,以便以后的任何调用都可以访问。

source

#3


4  

Thats the compilation of asp.Net pages into intermediate language + JIT compilation - it only happens the first time the page is loaded. (See http://msdn.microsoft.com/en-us/library/ms366723.aspx)

这就是asp的汇编。将网页转换为中级语言+ JIT编译—只在第一次加载页面时发生。(参见http://msdn.microsoft.com/en-us/library/ms366723.aspx)

If it really bothers you then you can stop it from happening by pre-compiling your site.

如果它真的困扰你,那么你可以通过预编译你的站点来阻止它的发生。

EDIT: Just re-read the question - 60 seconds is very long, and you would expect to see some processor activity during that time. Check the EventLog for errors / messages in the System and Application destinations. Also try creating a crash dump of the w3wp process during this 60 seconds - there is an chance you might recognise what its doing by looking at some of the call stacks.

编辑:只要重新阅读这个问题——60秒是很长的一段时间,你将会看到一些处理器的活动。检查EventLog以查找系统和应用程序目的地中的错误/消息。也可以尝试在这60秒内创建w3wp进程的崩溃转储——通过查看一些调用堆栈,您可能会发现它在做什么。

If it takes exactly 60 seconds each time then its likely that its waiting for something to time out - 60 seconds is a nice round number. Make sure that it has proper connections to the domain controllers etc...

如果每次都要花60秒,那么它很可能在等待某物超时——60秒是一个很好的整数。确保它与域控制器等有适当的连接。

(If there are some IIS diagnostic tools that would do a better job then I'm afraid I'm not aware of them, this question might be more suited to ServerFault, the above is a much more developer-ish approach to troubleshooting :-p)

(如果有一些IIS诊断工具可以做得更好,那么我恐怕我没有意识到它们,这个问题可能更适合于服务器故障,上面是一个更加开发的解决方法:-p)

#4


4  

I found that there was a network delay making an initial connection from the front end web server to the database server.

我发现存在一个网络延迟,导致从前端web服务器到数据库服务器的初始连接。

The issue was peculiar to Windows 2008 and our specific network hardware.

这个问题是Windows 2008和我们的特定网络硬件所特有的。

The resolution was to disable the following on the web servers:

决议是在web服务器上禁用以下内容:

#5


2  

Greater than 60 seconds sounds fishy. Try running a test.html page to see how long that takes. That will isolate IIS7's role.

超过60秒听起来很可疑。尝试运行一个测试。看看需要多长时间。这将孤立IIS7的作用。

Then temporarily rename your web.config, global.asax and application folders and try a test.aspx page (very simple page). That will isolate ASP.NET.

然后暂时重命名您的web。配置,全球。asax和应用程序文件夹并尝试一个测试。aspx页面(非常简单的页面)。将隔离ASP.NET。

If both of those are fast (i.e. about 10 seconds), then it's your application. But, if either are slow then not the application and something with the server itself.

如果两者都是快速的(即大约10秒),那么这就是你的应用程序。但是,如果两者都很慢,那么不是应用程序和服务器本身。

#6


1  

This hat nothing to do with JIT compiling. The normal C# compiler compiles your code behind files (.aspx.cs) into intermediate language into an assembly at startup if this assembly dont exist or code files have changed. Your web site assembly is located in the "bin" folder of your web site.

这与JIT编译无关。正常的c#编译器将您的代码在文件(.aspx.cs)中编译成中间语言,如果这个程序集不存在,或者代码文件发生了变化,那么在启动程序中就会生成一个程序集。您的web站点组装位于web站点的“bin”文件夹中。

In fact the JIT compiling occures after that, but this is very fast and won't take several minutes. JIT Compiling happens on every startup of an .net application and that won't take more than a view seconds.

实际上,JIT编译发生在这之后,但是这非常快,不会花几分钟的时间。JIT编译发生在。net应用程序的每一次启动上,这只需要几秒钟的时间。

You can avoid the copmpiling of your web site if you deploy the already compiled website assembly (YourWebsite.dll) into the bin folder. It is also possible to deploy only the aspx files and leave the code behind files (aspx.cs) files away.

如果将已经编译好的网站程序集(YourWebsite.dll)部署到bin文件夹中,就可以避免web站点的复制。也可以只部署aspx文件并将代码留在文件(aspx.cs)文件之外。