asp.net 性能调较

简介:

由于asp.net 处理进程在machine.config配置文件中的配置为<processModel autoConfig="true" />,这意味着你的asp.net 应用程序使用的性能参数依赖于machine.config的配置。
下面几个参数是自动配置的:

  1. maxWorkerThreads 和 maxIoThreads
  2. minFreeThreads 和 minLocalRequestFreeThreads
  3. minWorkerThreads
  4. maxconnection
  5. executionTimeout

这几个参数会和你的应用程序发生这样的症状相关“争用、 性能下降和死锁进行 Web 服务请求从 ASP.NET 应用程序时”:

进行从 ASP.NET 应用程序, 调用 XMLWeb 服务时可能会遇到争用、 性能下降和死锁。 客户可能报告请求停止响应 (或 " 挂起 ") 或需要很长时间来执行。 如果怀疑死, 可能回收辅助进程。 应用程序事件日志中可能会收到以下消息。 • 如果您使用 MicrosoftInternet 信息服务 (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 有是没有足够的空闲线程 ThreadPool 对象以完成 operation.ö 中: 
还可能在浏览器收到以下异常错误信息: 
请求定时 out.ö ôHttpException (0 x 80004005): 
注意 本文还适用于应用程序直接使 HttpWebRequest 请求。

原因

因为 ASP.NET 的辅助线程和完成端口线程, 调用可用于执行请求数限制可能发生此问题。 

对 Web 服务调用通常, 使用一个辅助线程来执行代码发送请求和一个完成端口线程以从 Web 服务接收回调。 但是, 如果请求重定向或需要验证, 调用可能使用多达两辅助和两完成端口线程。 同时发生多个 Web 服务调用时, 因此您可消耗托管 ThreadPool。 

例如, 假设 ThreadPool 仅限于 maxworkerthreads, 10, 并且当前执行所有 10 工作线程正在等待回调来执行代码。 由于工作项排队以 ThreadPool 阻塞线程可用之前可从不执行回调。 

其他潜在源争夺是 maxconnection 参数, System.Net 命名空间用于限制的连接数。 此限制通常, 按预期工作。 但是, 如果许多应用程序尝试使许多请求到单个 IP 地址同时, 线程可能需要等待一个可用连接。 

解决方案
Machine.config 文件以最适合您情况中要解决这些问题, 可调整以下参数: • maxWorkerThreads 
• minWorkerThreads 
• maxIoThreads 
• minFreeThreads 
• minLocalRequestFreeThreads 
• maxconnection 
• executionTimeout 
要成功解决这些问题, 请按照下列步骤操作: • 限制同时到大约 12 每 CPU 执行, ASP.NET 请求的数量。  
• 允许 Web 服务回调用于 ThreadPool 中自由线程。  
• 选择一个适当值对于 maxconnections 参数。 根据您选择的 IP 地址和 AppDomains 使用数。  
注意 : 建议来限制每 CPU 12 ASP.NET 请求的数量是有点任意。 但是, 此限制已证明能够适合大多数应用程序。 

本文来自云栖社区合作伙伴“doNET跨平台”,了解相关信息可以关注“opendotnet”微信公众号
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
6月前
|
存储 开发框架 前端开发
asp.net与asp.net优缺点及示例
asp.net与asp.net优缺点及示例
|
.NET Windows
ASP.NET速度优化
用过ASP.NET的人都知道吧,页面首次打开很慢,本来网站第一次启动就慢,但别的页面如果没有访问过的第一次访问也会慢。 原因:asp.net程序第一次运行需要验证数字签名,这个验证需要远程连接微软服务器去验证,明显会让用户感觉速度很卡,当服务器是无法连接到外网时,这个校验证书的过程需要等到timeout之后才会结束,有时候会延迟很久。
890 0
|
XML 缓存 前端开发
如何真正提高ASP.NET网站的性能
前言 怎么才能让asp.net网站飞得更快,有更好的性能?——这是很多开发者常常思考的一个问题。我有时候会做大量的测试,或请求别人帮忙采集一些数据,希望能够验证网上一些专家的建议或证明自己的一些猜想。 理论上讲,我们希望能开发出性能最优的网站,但是公司能否承担为此要付出的成本?这是实践过程中常常遇到的矛盾。
959 0
|
.NET
Asp.Net customErrors与httpErrors的区别
先看一下简单的对比 customErrors Asp.Net级别的错误处理程序,只处理Asp.Net应用抛出的异常(404,403,500。。) 在IIS7+的服务器依然可用(IIS7之前就引进了) 静态文件(如.
1065 0
|
.NET
详解ASP.NET页面的asp“.NET研究”x扩展
  需求:某网站因业务扩展,需拆分出另一个站点,新旧站点具有相同的内容,但具体栏目表现形式上不一样。原网站运行多年,有大量的图片,这些图片也会在新站上使用。任务是:   保证两个网站图片内容同步,即原来的站点增加一个图片,新站点即可使用这个图片。
698 0
|
存储 缓存 .NET
|
.NET 开发框架 前端开发
|
.NET 开发框架 Windows