博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
asp.net 性能调较
阅读量:5861 次
发布时间:2019-06-19

本文共 2595 字,大约阅读时间需要 8 分钟。

由于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 请求的数量是有点任意。 但是, 此限制已证明能够适合大多数应用程序。
本文转自 张善友 51CTO博客,原文链接:http://blog.51cto.com/shanyou/73175,如需转载请自行联系原作者
你可能感兴趣的文章
第二周作业
查看>>
Action获取请求参数的三种方式中的第一种
查看>>
使用SQL访问MongoDB
查看>>
function 与 => 的区别
查看>>
GitHub
查看>>
kali linux常用wifi攻击工具
查看>>
JS字符串数组转换
查看>>
2019年全国统一高考数学试卷理科新课标Ⅲ
查看>>
VBScript:写excel的例子
查看>>
SpringMVC(十二)自定义异常处理器 HandlerExceptionResolver(接口)
查看>>
接口测试(一)--基础知识
查看>>
lombok 介绍及基本使用方法
查看>>
实验一 巩耀阳 201421430029
查看>>
Inkpad绘图原理浅析
查看>>
043_关于Salesforce集中权限的解释
查看>>
TYVJ P1077 有理逼近 Label:坑,tle的好帮手 不懂
查看>>
相对路径和绝对路径
查看>>
java线程面试题摘要
查看>>
Vue 给axios做个靠谱的封装(报错,鉴权,跳转,拦截,提示)
查看>>
asp.net SqlParameter关于Like的传参数无效问题
查看>>