调试部署在IIS上的ASP.NET程序实用小技巧

远程调试ASP.NET程序,似乎是每一个做ASP.NET的人都肯定要掌握的技能,大家都知道,从IIS6开始,就有了application pool(应用程序池)的概念,每个应用程序池都会有单独的worker process,这样可以保障不同的应用程序池之间互相不会影响,就好像MySpace上有博客应用,有论坛应用等等……如果这些应用都用的同一个应用程序池,那么只要一个挂了,其他的也跟着挂。但是如果每个站点都单独使用一个应用程序池,那么A站点挂了对B站点不会有影响。同时如果A站点有部署更新,需要回收应用程序池,B站点不受影响,照常工作。

创建多个应用程序池虽然好处多多,不过却增大了调试的难度。假如一台服务器上有5个站点,那么正常运行的情况下就会有5个w3wp.exe进程,要找到合适的进程进行调试就是一个问题,以前比较笨,就看哪个进程的ID比较小,或者哪个进程占用的内存较多来“判断”,今天发现其实微软有一个非常靠谱的方法。

1. 打开一个命令行窗口

2. 浏览到“Windows > System32”

3. 运行“cscript iisapp.vbs”

得到如图结果,哪个应用程序池对应哪个W3WP.EXE一目了然,从此告别瞎猜

IIS-WORKER-PROCESS

用Python脚本对ASP.NET站点进行预热

很多人可能都会注意到,当一些新的代码部署到一个ASP.NET的站点后,第一次访问的时候是非常慢的,有可能需要等待超过一分钟;如果我们更新了站点的bin目录下的一些dll文件,那么这种情况会变得更加明显。当第一个页面请求到达服务器的时候,IIS会重新编译文件,这时候可以观察到w3wp.exe和csc.exe都会占用很多CPU。我们不希望用户是IIS重启之后第一个访问者,所以每台服务器在上线之前,都需要做预热处理。所谓预热处理,原理很简单,就是向目标服务器发送一些HTTP请求,从而触发服务器对文件进行编译,实现预热。

为什么用Python?一位大师曾经说过,程序员要每6个月就要学习一门新的语言(这个要求还真苛刻),所以决定学习一下Python。

需求:其实这个需求特别简单
1. 发送HTTP请求,Python自带的httplib库就能满足这个需求了
2. 多线程访问不同的站点,现在MySpace常用站点至少有4个
3. 指定服务器的IP,因为测试的服务器也有多台
4. 获取HTTP请求的状态
5. 需要在登录状态下进行预热
Continue reading “用Python脚本对ASP.NET站点进行预热”

用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息

前两篇文章介绍了VSTS性能分析工具Profiler如何用Profiler发现性能问题并且进行优化。今天想分享一下如何在测试ASP.NET程序的过程中获取代码覆盖率的信息。

设想如下场景,测试人员介入到项目的需求,分析,设计的阶段,得到了很多有用的文档和信息。接下来就到了编码的阶段,在这个时候测试工程师开始根据前面获得的信息来设计测试用例,做用例评审,力求测试用例覆盖能覆盖系统的每一个角落。不幸的是,系统实在是太大,没有人能确切地知道手上的测试用例对系统的覆盖(这里指定为代码的行覆盖)能达到什么样的程度。对于系统的关键部分,没有人希望在经过几轮测试以后,还有相当部分的代码是没有被执行过的。

解决这个问题的其中一个方法,就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候,得益于IDE的帮助,代码覆盖率信息很容易就能得到,但是对于部署在IIS上的ASP.NET代码,又如何去收集代码覆盖率信息呢?曾经找过好多.NET的代码覆盖率工具,没有合适的。不过就在最近,让我发现了VSPerfMon,VSTS自带的性能数据收集工具。真是众里寻他千百度,蓦然回首,那工具却在灯火阑珊处。

1. 首先要对需要进行代码覆盖率信息收集的二进制文件(DLL, EXE)用VSInstr进行处理,记得带上/COVERAGE参数

VSInstr “D:\Websites\somewhere\bin\MySpace.Web.UserHome.dll” /COVERAGE

2. 停掉IIS

iisreset /stop

3. 用VSPerfClrEnv 设置相关的环境变量

VSPerfClrEnv /globaltraceon

4. 启动VSPerfMon;参数/COVERAGE代表本次监控收集的数据是代码覆盖率;/user:”NETWORK SERVICE”,指定用户名;/CS 启用跨域会话分析;/output:”d:\magus\0422.coverage”,指定输出文件的名字和路径,记得用.coverage作为扩展名。
Continue reading “用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息”

用VSTS Profiler发现性能问题并且进行优化实例

上一篇文章介绍了如何使用VSTS的Profiler,今天想分享一下对于一个ASP.NET应用程序,用Profiler找到性能问题并且对之进行优化。

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

iis-sample

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

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

instr-function-with-indi-work1

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

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

VSTS性能分析工具Profiler的介绍

MSDN文档中,对于VSTS中的Development Edition的介绍主要分两大块,第一是“编写高质量的代码”,第二就是“使用分析工具对应用程序性能进行分析”。在VSTS里面有一个工具,叫Profiler,这个工具可以帮助研发人员在程序运行的过程中收集相关的数据,并且对之进行分析,从而达到帮助实现性能调优的目的。本文讲述如何在使用命令行工具来对ASP.NET程序进行性能测试相关数据的收集。

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

how-sampling-works

对于检测模式,他的工作原理是用VSInstr程序在原始的代码中插入一些用于计算时间的代码,例如A函数调用B函数,那么在调用B函数的前后都会被插入用于计算时间的代码,具体可以看下图:
Continue reading “VSTS性能分析工具Profiler的介绍”

利用序列化和反序列化实现深拷贝

假如说有一个简单的类,只有2个属性,那么可以用比较简单的方法实现深拷贝。

[Serializable]
public class Person
{
    public int Height { get; set; }
    public string FirstName { get; set; }
}

class Program {
    static void Main(string[] args) {
        //实例化一个对象
        Person PersonOne = new Person();
        PersonOne.FirstName = "John";
        PersonOne.Height = 1;
        //深拷贝
        Person DeepCopyPerson = new Person();
        DeepCopyPerson.FirstName = PersonOne.FirstName;
        DeepCopyPerson.Height = PersonOne.Height;
    }
}

Continue reading “利用序列化和反序列化实现深拷贝”

单元测试中三种准备Test Fixture的方法比较

首先说一下Test Fixture,我不知道怎么样翻译这个Test Fixture,没能搜到一个翻译的比较合适的。最让我气愤的是某人翻译的一本书中,直接把Test Fixture翻译成为测试夹具,这明显就是什么词霸词典硬翻译出来的,我强烈鄙视这样不负责任的翻译行为。

The test fixture is everything we need to have in place to exercise the SUT

我觉得这是一个对Test Fixture的一个很清晰明了的定义,就是运行被测软件所需要的一切东西,这个“东西”不单只是数据,同时还包括对被测软件的准备,例如实例化某个被测方法所在的类,准备数据库的ConnectionString等。通常来说,有三种方法来准备Test Fixture。

1. 内联方式:这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复,出现很多复制粘贴的代码。同时,如果这个SETUP的过程比较复杂,也会降低测试代码的可读性,可维护性。另外的一个问题就是,这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点,这种方法还有什么生命力呢?首先,可能对于初学者来说,这种方法是最简单的;其次,在一些只需要准备简单的Test Fixture的场合中,这种方法还是给编写测试的人提供了便利。
Continue reading “单元测试中三种准备Test Fixture的方法比较”

.NET平台上的Memcached客户端介绍

早上接到一个任务,需要对Linux服务器的Memcached的update操作进行性能测试,我发现我是一个典型的“手里拿着锤子,就把所有问题都当成钉子”的人。我第一个念头就是,上Memcached的官网找.NET的客户端。最后在Codeplex上找到了一个叫Memcached Providers的客户端程序,很小,218K,里面就3个DLL,一个是Memcached Providers本身的DLL,还有一个是Enyim.Caching,Enyim.Caching也是一个.NET平台上的Memcached客户端,最后就是著名的log4net。

Memcached Providers的配置很方便,首先就是在.NET项目中引用上述提到的3个DLL文件,然后就需要修改项目的配置文件,如果是桌面程序,就修改APP.CONFIG,如果是WEB程序,就修改WEB.CONFIG。
Continue reading “.NET平台上的Memcached客户端介绍”

ASP.NET中配置文件web.config的优先级

web.config是ASP.NET的默认配置文件名,一般来说每个ASP.NET站点的根目录都会有一个web.config,因为在VS里面建立站点的时候会一同生成的。其实在一个站点的不同的目录中可以各自有各自的web.config文件,如果一个站点中的不同的目录都有web.config,那么他们之间的关系是什么?哪个web.config的优先级会高呢?顺序如下:
(1) 如果在当前页面所在目录下存在web.config 文件,查看是否存在所要查找的结点名称,如果存在返回结果并停止查找。
(2) 如果当前页面所在目录下不存在web.config 文件或者web.config 文件中不存在该结点名,则查找它的上级目录,直到网站的根目录。
Continue reading “ASP.NET中配置文件web.config的优先级”

LINQ查询操作中的类型关系

最近在测试中,想尝试用LINQ来简化一下测试的代码,初步学习了一下LINQ,个人感觉需要认真理解查询操作中的类型关系,在阅读MSDN文档后写下了本文,主要参考MSDN讲述理解查询操作中的类型关系,还有对C# 3.0的一个新的关键字var的理解。

首先有一段LINQ查询表达式的代码

List ret = AccountGateway.AccountLiteProvider.GetOnlineUsers(1, 10000);
var query = from onlineUser in ret
			where (onlineUser.UserId > 1301000200)
			select onlineUser.UserId;
foreach(int iUser in query)
{
	Console.WriteLine(iUser.ToString());
}

Continue reading “LINQ查询操作中的类型关系”