在测试过程中，我们经常需要知道“系统的资源利用情况”来监测我们的测试执行情况，来查看测试环境是否有效，测试结果是否可信，或者是在无人值守时保存结果，等我们值班时再来分析。
1、在Windows环境下，“开始运行”中输入“perfmon”，调出性能管理窗口；
2、在控制台节点中选择“性能日志和警报计数器日志”；
3、在右侧的空白窗口中右击选择“新建日志设置”，在弹出的窗口中输入新建日志的名称，如PerfTest，确定； 如图：
<IIS站点，则选择Web Servie 项 , 最后选择左下角具体的站点项目>
//=========================================================================================
一个ASP.NET项目在运营中，当接口并发量达到200左右时，IIS出现了明显的请求排队现象，发送的请求都进入等待，无法及时响应，Cpu接近100% 。花了很多时间精力解决这个问题，其中百度找了一解决方案，供大家参考。
注意到只有对于.aspx或.ashx的请求才会延迟，而.htm或.jpg文件都是即时响应的，我选择了性能监视器中的ASP.NET 4.0中的2个主要计数器：Requests Current（当前请求数）, Requests Queued（被排队的请求数），如下图：(在左上角的列表中选择asp.net 4.0, 双击选择左下角的二个目标，完成添加)
进行观察。通过观察发现，当前请求数达到200左右时，被排队的请求数就从0开始上升，一直到50左右，如果请求数继续上升，则被排队数也随之上升。当被排队的请求数>0时，就意味着这个时候去访问任何.aspx页面，页面都会处于长时间等待中，没有任何响应，直到IIS处理完了其他请求，才会开始处理队列中的请求。也就是说，当排队数长期>0时，系统基本处于不可用的状态。就是说200个并发请求下，几乎所有的请求都被排队了，如下图
针对以上问题，查阅了相关资料，是否出现排队是和应用程序池的可用线程有关，通过2个方法可以查看系统总线程数和当前可用线程数。
ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);
在队列请求数达到120左右时，通过此方法，得到maxWorker=1600，而availableWorker=1472
因为服务器是16核的，ASP.NET4.0默认每核可以使用100个线程，所以maxWorker是1600，1600-120=1480，大致相等。
就是说当前有120个线程被用来处理请求，还有1400多个处于空闲。关键问题就是为什么这些空闲线程没有被及时启用？
ASP.NET提供的线程配置参数中，有一个参数是非常重要，但是可能被大家忽略的，就是minWorkerThreads。
意指最小工作线程，根据我们以上的测试结果，IIS托管线程启动非常慢，微软也认识到了这个问题，所以提供此参数用于设置正常情况下的最小工作线程数。比如我们系统白天的并发在200-300之间，则可以设置最小线程为300，这样系统响应速度可以大幅提高。
据此，我对配置文件（machine.config）进行了如下修改。注意都是针对单个CPU的，系统会自动乘以逻辑CPU的数量。
<system.web>
<processModel autoConfig="false" maxWorkerThreads="200" minWorkerThreads="50" />
本文转自:http://www.cnblogs.com/Fooo/p/3341775.html
其他相关参考网站:http://www.cnblogs.com/tianguook/p/5204757.html