争用、 较差的性能和死锁时使 ASP.NET 应用程序的 Web 服务请求
2012-07-17 18:26
281 查看
文章编号: 821268 - 查看本文应用于的产品
症状
当您从
ASP.NET 应用程序调用 XML Web 服务时,您可能会遇到争用、 较差的性能和死锁。客户端可能会报告请求停止响应 (或"挂起"),或需要很长时间才能执行。如果怀疑死锁,则可能是回收工作进程。在应用程序事件日志中可能会收到以下消息。
如果您使用的 Microsoft Internet Information Services (IIS) 5.0,应用程序事件日志中收到以下消息:
如果您使用的 IIS 6.0,应用程序事件日志中收到以下消息:
如果您使用的 IIS 6.0,系统事件日志中收到以下消息:
当您调用HttpWebRequest.GetResponse方法时,也可能会收到以下异常错误消息:
"System.InvalidOperationException: 要完成此操作的线程池对象中没有足够的空闲线程。"
在浏览器中,您还可能收到以下异常错误消息:
"HttpException (0x80004005): 请求超时。"
注意这篇文章也适用于直接进行HttpWebRequest请求的应用程序中。
原因
因为
ASP.NET 限制的辅助线程和调用可用于执行请求的完成端口线程的数量,可能会出现此问题。
通常情况下,调用 Web 服务使用一个工作线程来执行发送请求的代码和一个完成端口线程,以接收来自 Web 服务的回调。但是,如果请求被重定向或要求进行身份验证,该调用可能会使用两个工作和完成端口的两个线程。因此,您可以在同一时间发生的多个
Web 服务调用时耗尽托管线程池。
例如,假设线程池仅限于 10 个工作线程,并且所有 10 个工作线程当前正在执行正在等待回调来执行代码。因为要排队发送至线程池的任何工作项将被阻止,直到线程变为可用,可以永远不会执行回调。
另一个潜在源是争用的System.Net命名空间用于限制连接数的maxconnection参数。通常情况下,按预期方式工作此限制。但是,如果许多应用程序尝试对单个
IP 地址进行许多请求,在同一时间,线程可能必须等待可用连接。
解决方案
若要解决这些问题,可以在 Machine.config 文件以最适合您的具体情况调整以下参数:
maxWorkerThreads
minWorkerThreads
maxIoThreads
minFreeThreads
minLocalRequestFreeThreads
maxconnection
executionTimeout
要成功地解决这些问题,请执行以下操作:
限制可以为每个 CPU 的大约 12 同时执行的 ASP.NET 请求数。
允许 Web 服务回调用于自由线程的线程池。
选择适当的maxconnections参数的值。您的选择基于 IP 地址和使用的应用程序域的数量。
注意若要限制为每个 CPU 的 12 的 ASP.NET 请求数的建议是有点任意的。但是,此限制证明适用于大多数的应用程序。
ASP.NET 使用以下两个配置设置来限制最大的辅助线程和使用的完成线程数:
maxWorkerThreads 参数和 maxIoThreads 参数隐式相乘的 cpu 数量。例如对于如果两个处理器最大工作线程数是下列:
2 * maxWorkerThreads
ASP.NET 还包含下列确定多少工作线程和完成端口线程必须可用于启动远程请求或 $ 本地请求的配置设置:
ASP.NET 还包含确定多少辅助线程和完成端口线程必须可用于启动远程请求或本地请求的以下配置设置:
(maxWorkerThreads * number of CPUs)-minFreeThreads
注意minFreeThreads 参数和 minLocalRequestFreeThreads 参数是不隐式相乘的 cpu 数量。
作为 ASP.NET 1.0 Service Pack 3 和 ASP.NET 1.1 的 ASP.NET 还包含以下配置设置,用于确定多少工作线程可能会获得可立即向远程请求提供服务。
由该设置控制的线程可以创建多快的速度比从 CLR 的默认"线程调整"功能创建的工作线程。此设置使 ASP.NET 能够可能会突然填充到后端服务器突然突发的从客户端结束或任意位置类似的请求,将导致在队列中的请求数的突然增长的上一个 slow-down 由于 ASP.NET
请求队列的服务请求。minWorkerThreads 参数的默认值为 1。我们建议您将 minWorkerThreads 参数的值设置为下面的值。
默认状态下,minWorkerThreads 参数不是在 Web.config 文件或 Machine.config 文件中存在的。此设置是隐式乘以的 cpu 数量。
maxconnection 参数确定多少能连接到特定的 IP 地址。该参数将显示为以下形式:
Maxconnection参数确定多少能连接到特定的 IP 地址。参数即会出现,如下所示:
ASP.NET 使用以下配置设置来限制请求执行时间:
您还可以通过使用 Server.ScriptTimeout 属性来设置此限制。
注意如果增加 executionTimeout 参数的值,您可能还不得不修改 processModel responseDeadlockInterval 参数的设置。
建议在本部分中使用的设置可能不适用于所有应用程序。但是,以下附加信息可以帮助您进行相应的调整。
如果将一个 Web 服务调用单个 IP 地址到每个 ASPX 页从 Microsoft 建议您使用以下配置设置:
设置 maxWorkerThreads 参数和 maxIoThreads 参数的值为 100。
设置要 maxconnection 参数的值 12 * N (其中 N 是您所具有的 cpu 数)。
设置要 minFreeThreads 参数的值 88 * N,minLocalRequestFreeThreads 参数来 76 * N。
将 minWorkerThreads 的值设置为 50。请记住 minWorkerThreads 不是在默认情况下配置文件中。您必须将其添加。
这些建议的一些涉及一个简单的公式,涉及在服务器上的 cpu 数。该变量类型的值,该值代表公式中的 cpu 数是 N。对于这些的设置如果您具有超线程启用,则必须使用逻辑 cpu 数而不是物理 cpu 数。 例如对于如果您有一个在四处理器服务器与启用超线程,N 的值的公式中将是 8,而不是为 4。
注意您在使用此配置时您可以执行的每个 CPU 的 12 ASP.NET 请求的最大值在同一时间,因为 100 88 = 12。因此,至少 88 * N辅助线程和 88 * N 完成端口线程是可用的其他使用
(例如 Web 服务回调)。
例如对于您有一个带有四个处理器和启用超线程的服务器。基于这些公式,您可以使用下列值这篇文章中提到的配置设置。
此外,您在使用此配置时 12 连接都是每个 CPU 每个 IP 地址的每个 AppDomain 可用的。因此,在下面的情况下很少的争用发生请求正在等待连接,并在 ThreadPool 不已用完时:
在 Web 主机只能有一个应用程序 (AppDomain)。
ASPX 页的每个请求发出一个 Web 服务请求。
所有请求都都以相同的 IP 地址。
然而,您在使用此配置时涉及下列值之一的方案可能会使用太多的连接:
请求将多个 IP 地址。
请求会重定向 (302 状态代码)。
请求需要身份验证。
从多个 appdomain 发出请求。
例如,您有一个服务器具有四个处理器和启用超线程。基于这些公式,将使用本文中提及的配置设置的下列值。
状态
此行为是设计使然。
更多信息
如果您遇到较差的性能和使用 ASP.NET 的 IIS 7.0 中的争用,请参阅下面的 Microsoft 博客:
IIS 7.0 和 6.0 上的 ASP.NET 线程使用
http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx
IIS 7.0 中的 ASP.net 挂起
http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx
参考
有关详细信息,请访问下面的 Microsoft 开发人员网络 (MSDN) 的网站:
http://msdn2.microsoft.com/en-us/library/ms998549.aspx
属性
文章编号: 821268 - 最后修改: 2009年7月28日 - 修订: 11.0
这篇文章中的信息适用于:
Microsoft .NET Framework 2.0
Microsoft ASP.NET 1.1
Microsoft ASP.NET 1.0
关键字:
kbmt kbprb KB821268 KbMtzh
http://support.microsoft.com/kb/821268
症状
当您从
ASP.NET 应用程序调用 XML Web 服务时,您可能会遇到争用、 较差的性能和死锁。客户端可能会报告请求停止响应 (或"挂起"),或需要很长时间才能执行。如果怀疑死锁,则可能是回收工作进程。在应用程序事件日志中可能会收到以下消息。
如果您使用的 Microsoft Internet Information Services (IIS) 5.0,应用程序事件日志中收到以下消息:
Event Type: Error Event Source: ASP.NET 1.0.3705.0 Event Category: None Event ID: 1003 Date: 5/4/2003 Time: 6:18:23 PM User: N/A Computer: <ComputerName> Description: aspnet_wp.exe (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state. It did not send any responses for pending requests in the last 180 seconds.
如果您使用的 IIS 6.0,应用程序事件日志中收到以下消息:
Event Type: Warning Event Source: W3SVC-WP Event Category: None Event ID: 2262 Date: 5/4/2003 Time: 1:02:33 PM User: N/A Computer: <ComputerName> Description: ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.
如果您使用的 IIS 6.0,系统事件日志中收到以下消息:
Event Type: Warning Event Source: W3SVC Event Category: None Event ID: 1013 Date: 5/4/2003 Time: 1:03:47 PM User: N/A Computer: <ComputerName> Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'.
当您调用HttpWebRequest.GetResponse方法时,也可能会收到以下异常错误消息:
"System.InvalidOperationException: 要完成此操作的线程池对象中没有足够的空闲线程。"
在浏览器中,您还可能收到以下异常错误消息:
"HttpException (0x80004005): 请求超时。"
注意这篇文章也适用于直接进行HttpWebRequest请求的应用程序中。
原因
因为
ASP.NET 限制的辅助线程和调用可用于执行请求的完成端口线程的数量,可能会出现此问题。
通常情况下,调用 Web 服务使用一个工作线程来执行发送请求的代码和一个完成端口线程,以接收来自 Web 服务的回调。但是,如果请求被重定向或要求进行身份验证,该调用可能会使用两个工作和完成端口的两个线程。因此,您可以在同一时间发生的多个
Web 服务调用时耗尽托管线程池。
例如,假设线程池仅限于 10 个工作线程,并且所有 10 个工作线程当前正在执行正在等待回调来执行代码。因为要排队发送至线程池的任何工作项将被阻止,直到线程变为可用,可以永远不会执行回调。
另一个潜在源是争用的System.Net命名空间用于限制连接数的maxconnection参数。通常情况下,按预期方式工作此限制。但是,如果许多应用程序尝试对单个
IP 地址进行许多请求,在同一时间,线程可能必须等待可用连接。
解决方案
若要解决这些问题,可以在 Machine.config 文件以最适合您的具体情况调整以下参数:
maxWorkerThreads
minWorkerThreads
maxIoThreads
minFreeThreads
minLocalRequestFreeThreads
maxconnection
executionTimeout
要成功地解决这些问题,请执行以下操作:
限制可以为每个 CPU 的大约 12 同时执行的 ASP.NET 请求数。
允许 Web 服务回调用于自由线程的线程池。
选择适当的maxconnections参数的值。您的选择基于 IP 地址和使用的应用程序域的数量。
注意若要限制为每个 CPU 的 12 的 ASP.NET 请求数的建议是有点任意的。但是,此限制证明适用于大多数的应用程序。
maxWorkerThreads和maxIoThreads
ASP.NET 使用以下两个配置设置来限制最大的辅助线程和使用的完成线程数:<processModel maxWorkerThreads="20" maxIoThreads="20">
maxWorkerThreads 参数和 maxIoThreads 参数隐式相乘的 cpu 数量。例如对于如果两个处理器最大工作线程数是下列:
2 * maxWorkerThreads
minFreeThreads和minLocalRequestFreeThreads
ASP.NET 还包含下列确定多少工作线程和完成端口线程必须可用于启动远程请求或 $ 本地请求的配置设置:<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
ASP.NET 还包含确定多少辅助线程和完成端口线程必须可用于启动远程请求或本地请求的以下配置设置:
(maxWorkerThreads * number of CPUs)-minFreeThreads
注意minFreeThreads 参数和 minLocalRequestFreeThreads 参数是不隐式相乘的 cpu 数量。
minWorkerThreads
作为 ASP.NET 1.0 Service Pack 3 和 ASP.NET 1.1 的 ASP.NET 还包含以下配置设置,用于确定多少工作线程可能会获得可立即向远程请求提供服务。<processModel minWorkerThreads="1">
由该设置控制的线程可以创建多快的速度比从 CLR 的默认"线程调整"功能创建的工作线程。此设置使 ASP.NET 能够可能会突然填充到后端服务器突然突发的从客户端结束或任意位置类似的请求,将导致在队列中的请求数的突然增长的上一个 slow-down 由于 ASP.NET
请求队列的服务请求。minWorkerThreads 参数的默认值为 1。我们建议您将 minWorkerThreads 参数的值设置为下面的值。
minWorkerThreads = maxWorkerThreads / 2
默认状态下,minWorkerThreads 参数不是在 Web.config 文件或 Machine.config 文件中存在的。此设置是隐式乘以的 cpu 数量。
maxconnection
maxconnection 参数确定多少能连接到特定的 IP 地址。该参数将显示为以下形式:<connectionManagement> <add address="*" maxconnection="2"> <add address="65.53.32.230" maxconnection="12"> </connectionManagement>
Maxconnection参数确定多少能连接到特定的 IP 地址。参数即会出现,如下所示:
executionTimeout
ASP.NET 使用以下配置设置来限制请求执行时间:<httpRuntime executionTimeout="90"/>
您还可以通过使用 Server.ScriptTimeout 属性来设置此限制。
注意如果增加 executionTimeout 参数的值,您可能还不得不修改 processModel responseDeadlockInterval 参数的设置。
建议
建议在本部分中使用的设置可能不适用于所有应用程序。但是,以下附加信息可以帮助您进行相应的调整。如果将一个 Web 服务调用单个 IP 地址到每个 ASPX 页从 Microsoft 建议您使用以下配置设置:
设置 maxWorkerThreads 参数和 maxIoThreads 参数的值为 100。
设置要 maxconnection 参数的值 12 * N (其中 N 是您所具有的 cpu 数)。
设置要 minFreeThreads 参数的值 88 * N,minLocalRequestFreeThreads 参数来 76 * N。
将 minWorkerThreads 的值设置为 50。请记住 minWorkerThreads 不是在默认情况下配置文件中。您必须将其添加。
这些建议的一些涉及一个简单的公式,涉及在服务器上的 cpu 数。该变量类型的值,该值代表公式中的 cpu 数是 N。对于这些的设置如果您具有超线程启用,则必须使用逻辑 cpu 数而不是物理 cpu 数。 例如对于如果您有一个在四处理器服务器与启用超线程,N 的值的公式中将是 8,而不是为 4。
注意您在使用此配置时您可以执行的每个 CPU 的 12 ASP.NET 请求的最大值在同一时间,因为 100 88 = 12。因此,至少 88 * N辅助线程和 88 * N 完成端口线程是可用的其他使用
(例如 Web 服务回调)。
例如对于您有一个带有四个处理器和启用超线程的服务器。基于这些公式,您可以使用下列值这篇文章中提到的配置设置。
<system.web> <processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/> <httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/> </system.web> <system.net> <connectionManagement> <add address="[ProvideIPHere]" maxconnection="96"/> </connectionManagement> </system.net>
此外,您在使用此配置时 12 连接都是每个 CPU 每个 IP 地址的每个 AppDomain 可用的。因此,在下面的情况下很少的争用发生请求正在等待连接,并在 ThreadPool 不已用完时:
在 Web 主机只能有一个应用程序 (AppDomain)。
ASPX 页的每个请求发出一个 Web 服务请求。
所有请求都都以相同的 IP 地址。
然而,您在使用此配置时涉及下列值之一的方案可能会使用太多的连接:
请求将多个 IP 地址。
请求会重定向 (302 状态代码)。
请求需要身份验证。
从多个 appdomain 发出请求。
例如,您有一个服务器具有四个处理器和启用超线程。基于这些公式,将使用本文中提及的配置设置的下列值。
状态
此行为是设计使然。
更多信息
如果您遇到较差的性能和使用 ASP.NET 的 IIS 7.0 中的争用,请参阅下面的 Microsoft 博客:
IIS 7.0 和 6.0 上的 ASP.NET 线程使用
http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx
IIS 7.0 中的 ASP.net 挂起
http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx
参考
有关详细信息,请访问下面的 Microsoft 开发人员网络 (MSDN) 的网站:
http://msdn2.microsoft.com/en-us/library/ms998549.aspx
属性
文章编号: 821268 - 最后修改: 2009年7月28日 - 修订: 11.0
这篇文章中的信息适用于:
Microsoft .NET Framework 2.0
Microsoft ASP.NET 1.1
Microsoft ASP.NET 1.0
关键字:
kbmt kbprb KB821268 KbMtzh
http://support.microsoft.com/kb/821268
相关文章推荐
- 争用、 性能下降和死锁进行 Web 服务请求 ASP.NET 应用程序优化
- 【转】争用、 性能差、 和死锁时使从 ASP.NET 应用程序与 Web 服务的调用
- 争用、 性能差、 和死锁时从 ASP.NET 应用程序调用 Web 服务
- 通过使用客户端证书调用 Web 服务以便在 ASP.NET Web 应用程序中进行身份验证
- 【MSDN】ASP.NET Web 服务、企业服务和 .NET Remoting 的性能比较测试与建议
- ASP.NET Web应用程序与ASP.NET Web服务应用程序有什么区别
- ASP.NET Web应用程序与ASP.NET Web服务应用程序的区别
- WCF项目问题2-无法激活服务,因为它需要 ASP.NET 兼容性。没有未此应用程序启用 ASP.NET 兼容性。请在 web.config 中启用 ASP.NET 兼容性,或将 AspNetCompatibilityRequirementsAttribute.AspNetCompatibilityRequirementsMode 属性设置为 Required 以外的值。
- ASP.NET Web 服务、企业服务和 .NET Remoting 的性能
- ASP.NET XML Web 服务的应用程序集成
- ASP.NET Web 服务、企业服务和 .NET Remoting 的性能比较(有一些指标)
- 微软企业库5.0学习笔记(11)WCF和ASP.NET Web服务应用程序
- .NET Remoting与ASP.NET Web服务性能比较
- [转载]ASP.NET Web 服务还是 .NET Remoting:如何选择,使用 Microsoft .NET 建立分布式应用程序
- ASP.NET WebApi服务接口如何防止重复请求实现HTTP幂等性(八)
- 为Asp.net应用程序设置构建Web服务
- 性能比较:.NET Remoting 与 ASP.NET Web 服务
- 在Asp.net应用程序中构建基于WCF Web.Api的服务
- C#/ASP.NET应用程序配置文件app.config/web.config的增、删、改操作,无法为请求的 Configuration 对象创建配置文件。
- 无法激活服务,因为它不支持 ASP.NET 兼容性。已为此应用程序启用了 ASP.NET 兼容性。请在 web.config 中关闭 ASP.NET 兼容性模式或将 AspNetCompatibili