由于ASP.NET程序运行在一个硕大的框架上，所以一般用Sample模式收集到的数据，对发现性能问题帮助不大，以下是一个用Sample模式收集的结果：

从这个报告中我们可以看到，前5个工作量最大的函数和执行单独工作最多的函数都是系统函数。

下面看一下有针对性地用检测模式收集的数据：

本文就采用“检测”模式收集性能数据来进行分析和处理。

首先，把本次测试的目标DLL用VSInstr工具进行处理，使得Profiler能够收集相关的性能数据，这一个步骤非常关键，通常来说不需要设置额外的参数，就是默认的方式就可以了，例如：VSInstr “D:\Websites\xxxx\bin\xxxx.dll”，在处理的过程中可能会提示一些错误，具体错误的信息可以在这里查找。把相应的DLL处理完毕以后，就在命令行输入以下指令（命令行的指令用斜体加下划线表示；说明文字加黑）

停止IIS

iisreset /stop

设置分析.NET应用程序所需要的环境变量，在运行完这个命令以后需要重启。由于使用检测方式进行数据采集，所以这里我用globaltraceon参数。

VSPerfClrEnv /globaltraceon

启动性能数据收集。/start:trace，告诉收集器要收集检测数据；/user:”NETWORK SERVICE” ，由于是要对IIS进行的数据进行采集，所以需要制定用户NETWORK SERVICE；/CS，启用跨进程分析，看了一些文章说是分析ASP.NET程序一般都把这个选项打开，原因不详；/output:”d:\magus\0422.vsp”，指定输出文件的路径和名称；/wincounter:”\Processor(_Total)\% Processor Time”，收集处理器的参数，这里需要注意的是，wincouter后面的性能计数器名字一定要是全名，有一个方法可以查询系统的性能计数器的全称，就是用VSTS的Server Explorer，然后找到相应的服务器(一般是本机)，下面有一个“Performance Counters”；如果要收集多个性能计数器的数据，只需要多加几个 /wincounter 参数即可，例如我在收集处理器时间的同时，还想知道Context Switcher每秒的数据。

VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\magus\0422.vsp” /wincounter:”\Processor(_Total)\% Processor Time” /wincounter:”\System\Context Switches/sec”

在IIS起来之前先停止性能数据的收集

VSPerfCmd /globaloff

启动IIS

iisreset /start

对程序进行预热，这一步也是很关键，因为IIS启动以后，程序需要预热才能达到稳定的状态，因为程序首次被访问的时候有些代码会被编译，所以为了降低对性能测试的影响，应该现对被测的程序进行预热。在预热完毕以后重新启动性能数据的收集。

VSPerfCmd /globalon

– 运行性能测试场景 –

测试运行完毕以后，停止性能数据的收集

VSPerfCmd /globaloff

停掉IIS

iisreset /stop

关闭性能数据收集器，这一步完成以后就能生成包含数据的文件了

VSPerfCmd /shutdown

首先来看看收集到的报告

在这个方法里面有一段不知名方法（其实是因为没有相应的Symbol，⊙﹏⊙b汗）占用了大量的计算时间，然后就找到相应的代码，原来该不知名方法是一个动态生成的代码，该段代码大概就是会创建一个新的Client对象，然后向另外一台服务器发起一个请求。其实不用每次调用该方法都创建一个新的Client对象。然后我尝试着把这个Client改为静态变量，经过优化以后的报告对比如下：

效果还是挺明显的，但是当我重新测试一下性能的时候，被打击了一下，改动前后的性能对比相差很小，小的都可以认为是误差：P，因为在一个颇为庞大的项目中，这点小小的改动的确不可能影响大局。不过这次试验让我学会了用Profiler来找到ASP.NET运行中执行较慢的语句，并且看看这些语句有什么问题（可能是一个调用存储过程的方法很慢，而真正的原因是数据库有问题），定位问题所在，然后解决问题，最后回测一下对比改动前后的结果。看是否达到预期的优化效果。

Related posts:

1. VSTS性能分析工具Profiler的介绍
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. Linux下的snmpd.conf配置说明

在VSTS的Profiler中，有两种(VSTS2010好像有5种了)Profiling的方法，第一种是采样(Sampling)，第二种是检测(Instrumentation)。对于采样模式，它的工作原理是Profiler定期中断CPU并且收集函数的调用堆栈信息。在网上找到一个图，对于采样工作方式的描述非常清晰：

对于检测模式，他的工作原理是用VSInstr程序在原始的代码中插入一些用于计算时间的代码，例如A函数调用B函数，那么在调用B函数的前后都会被插入用于计算时间的代码，具体可以看下图：

下面我自己写了一个小的Sample类，然后把编译好的代码用Reflector来查看，很容易地就能看出区别。第一个图是没有经过VSInstr处理的原始代码：

下图就是经过VSInstr处理后，反编译后的代码：

可以看到VSInstr程序修改了原来的DLL。在检测模式下，只有经过修改后的DLL才能收集到数据。

在VSTS中，一般可以通过Analyze菜单下的Launch Performance Wizard来新建一个性能会话，然后进行性能数据的采集。

对于ASP.NET程序，可以通过以下步骤来进行“采样”

iisreset /stop
VSPerfClrEnv /globalsampleon
VSPerfCmd /start:sample /user:”NETWORK SERVICE” /output:”d:\somewhere\xxxx.vsp”
VSPerfCmd /globaloff
iisreset /start
VSPerfCmd /attach:xxxx
VSPerfCmd /globalon

–run the test scenario–

VSPerfCmd /globaloff
VSPerfCmd /detach
iisreset /stop
VSPerfCmd /shutdown

1. 第一步是停掉IIS
2. 然后通过VSPerfClrEnv对环境变量进行设置，具体可以查文档，做完这一步以后通常需要重启一下电脑
3. 第三步就是通过VSPerfCmd启动性能数据收集
4. 接下来的VSPerfCmd /globaloff就是暂停性能数据的收集
5. 然后重启IIS，并且访问一下这个服务器上的页面，使得W3WP进程启动
6. 查看W3WP.EXE的进程ID，然后通过VSPerfCmd /attach:xxxx把Profiler attach到IIS中
7. 通过VSPerfCmd /globalon重新让Profiler进行性能数据的采集
8. 然后就可以运行性能测试的场景
9. 运行测试完毕以后就用VSPerfCmd /globaloff停止性能数据的采集
10. 接着用VSPerfCmd /detach让Profiler不要附着在IIS上
11. 停掉IIS — iisreset /stop
12. 执行VSPerfCmd /shutdown，这一步执行完毕以后，在d:\somewhere\下就有一个xxxx.vsp的性能报告。

对于ASP.NET程序，可以通过以下步骤来进行“检测”

检测和采样其实是大同小异的，但是有一个关键的步骤就是在进行检测之前，一定要记得用VSInstr命令对需要进行检测的DLL或者EXE文件进行处理，建议一次不要检测太多文件，检测时间不要太长，因为检测所产生的数量是非常大的，产生的文件大小都是按G级别计算了。

iisreset /stop
VSPerfClrEnv /globaltraceon
VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\xxx\0422.vsp”
VSPerfCmd /globaloff
iisreset /start
– 预热 –
VSPerfCmd /globalon

–run code–

VSPerfCmd /globaloff
iisreset /stop
VSPerfCmd /shutdown

重复一次，在做以上的步骤之前必须要用VSInstr对目标二进制文件进行处理。这里详细步骤就不做解释了，命令的主要区别就是在做检测的时候，就免去了Attach到IIS这个步骤了。

采样和检测，前者是宏观的性能数据采集，后者是微观的性能数据采集。对于CPU负载较高的程序，用采样会得到比较好的效果；但是如果程序运行过程中并没有消耗很多的CPU资源，那么用采样可能就不能收集到太多有用的信息。所以在不同的场景下需要应用不同的性能数据收集方法。

Related posts:

1. 用VSTS Profiler发现性能问题并且进行优化实例
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. VSTS 2010 Test Edition文章收集

然后去微软的网站下载Visual Studio Team System Test Load Agent试用版。是一个ISO文件，用虚拟光驱挂上，然后开始安装。

如果要把Controller和Agent都安装在同一台电脑上，需要先安装Controller。安装的时候需要输入Windows的帐户和密码。整个过程不会太长，期间会默认安装SQL 2005 EXPRESS版，因为controller需要把测试的结果记录在数据库中。

安装好了controller以后，就可以安装Load Agent了，如图，也是需要输入windows的帐户和密码：

安装Agent会比安装controller多一个步骤，就是要指定controller，这里需要输入的controller的计算机名字，而不是什么LocalHost……

如果都安装成功的话，可以在任务管理器里面找到以下3个进程：QTAgent.exe, QTAgentService.exe和QTController.exe

至此， Test Load Agent算是安装成功了，现在进入配置环节。

打开VSTS，配置Test Controller，如图：

进入配置菜单以后，需要配置：

控制器的名字：这里应该是计算机的名字，例如magusvm2003se

Load Test Result Store：由于安装控制器的时候顺带安装了SQLEXPRESS，所以就用这个数据库

Agent：添加一个Agent，由于Agent也安装在一台机子上，所以就选择本机就好了。注意！状态需要为Ready才是正确的配置。

至此，Load Agent算是配置完毕了，但是还不能使用，因为当前的测试还没有配置为使用Load Agent来产生负载。

每一个测试项目，都有一个测试配置文件，现在我们就来修改这个测试配置文件吧，如图：

进入配置的窗口以后如图：需要把控制器选择为Remote，虽然其实是本地，但是从模式上来说就是Remote的。也因为只有选择Remote以后，才能选择controller，填入controller名字，这个名字是计算机的名字！！！

到了这一步，就算是配置完成了，攻击吧，8个核心的压力机！

最后希望大家能多讨论VSTS自带的性能测试工具，其实VSTS的LOAD TEST也是很强大的，还有推荐一篇关于如何安装Load Test Agent的文章

http://blogs.msdn.com/edglas/pages/load-agent-and-load-controller-installation-and-configuration-guide.aspx

Related posts:

1. VSTS 2010 Test Edition文章收集
2. 实现数据驱动的CodedUI Test