[摘要]
当认真地制定好测试方案后,实际进行测试的过程是很简单的。性能测试的第一步是使用类似Microsoft Web Application Stress Tool的工具对Web站点进行强度测试,测定Web服务器每秒种所能处理的最大请求数,这是定量的测量。第二步确定CPU,内存或终端设备中哪一项限制了每秒请求数达到更高的水平;这个过程与其说是一门测量技术,倒不如说是一门艺术。
先选择你...
当认真地制定好测试方案后,实际进行测试的过程是很简单的。性能测试的第一步是使用类似Microsoft Web Application Stress Tool的工具对Web站点进行强度测试,测定Web服务器每秒种所能处理的最大请求数,这是定量的测量。第二步确定CPU,内存或终端设备中哪一项限制了每秒请求数达到更高的水平;这个过程与其说是一门测量技术,倒不如说是一门艺术。
先选择你计划运行的ASP页面(寻找并使用站点上最慢的页面),这要根据访问数据库最频繁和查询量最大最复杂的页面来确定。这一点非常重要,最好是宁可包括一些不在这之内的更多的页面,也不要遗漏一些关键的代码路径。另外如果有可能的话,可以考虑象实际中一样,按照特定的顺序访问一系列页面,将cookie和查询字符串传递到每个页面来测试程序。
注意 根据实际程序的不同,可能有必要为测试准备一些ASP页面。其中的一些页面会需要通常由应用程序生成的代码参数,这些参数Web强度测试工具是不能生成的。
在Internet Information Server上运行程序时,应当对下列指标进行监测(用Performance Monitor)。
Active Server Pages :每秒请求安息,被拒绝的请求数,总队列长度和当前对话数
Inetinfo 进程 : 私有字节,虚拟字节和打开的句柄数量
处理器 : 用户使用时间和特许时间百分率的比值
注意 如果程序在Windows NT 4.0下运行于独立的内存中(或在 Windows 2000中将 Stress Properties 页的 Application Protection 设为 High [Isolated] ),就应当监测mtx.exe(在Windows 2000 里是dllhost进程)而不是Inetinfo进程。
如下图所示;Performance Monitor里每秒Active Server Pages请求数将显示程序的实际吞吐能力(在本例中是 1.000 Requests/Sec ),这一数据使得你能对高强度下Internet Information Server的性能进行分析,然后找到潜在的瓶颈的精确位置。反过来也使你可以判断程序在可接受的响应时间下,所能承受的最大用户数。
图三。性能监控器
使用ASP技术的Web服务器在启动时,从已经建立的大量线程中为每个页面请求都指定一个线程;如果所有的线程都已经被使用了,就将后续的页面请求排在队列中。在Performance Monitor中对总队列长度进行监视,可以确定有多少客户在等待服务器的响应。
最为常见的两个关系到数据库强度性能,与硬件无关的问题就是死锁和并行锁定。在数据服务器上使用数据存储器自带的Performance Monitor监视器时,至少应当对下列各指标进行监视。
锁定请求
每秒死锁数
每秒运算表格锁定的增加
用户连接
正在进行的处理
Web应用程序的设置同时也应该利用到OLE DB 资源合并的优点,这个应用程序由中间层OLE DB provider for Microsoft SQL Server 7.0自动进行管理的。先创建每一页面基础对象的连接,然后立即释放它们,通过这一方法,可以用很少的打开数据库的连接,处理成千上万个并行用户,这样就保护了数据库的资料,也提高了稳定性,这个增强的性能要用跟踪数据服务器上用户连接数的方法来进行监测(使用Performance Monitor)。当访问量增大时,用户连接数应该保持稳定,因为资源合并控制了在数据服务器上实际生成的连接数。
要达到预期的性能,依据数据库对程序进行调试的过程是非常关键的,所以必须作为开发周期的一个重要环节。这一过程包括对分配内存的大小,程序在各磁盘驱动器和控制器上分布,以及ActiveX组件的机器位置进行优化。只要有可能,就特别应该考虑消除进程之间数据的排队问题,因为这会占用非常大的运算量。
运行测试的时间,应是预期的实际用户环境中程序连续运行时间的一半以上。许多问题,尤其是内存不足,只有当程序运行了较长的一段时间后才会出现。
测试中应寻找的问题
Performance Monitor中每个指标的平均值是由程序与硬件的配置共同决定的。所以进行测试的时候,应当注意每一个指标是否偏离了平均值。
监测Internet Information Server
在寻找系统瓶颈时,Internet Information Server上最需要进行监测的是下面各项:
CPU利用率
内存使用情况
吞吐能力
在测试过程中,根据设计的程序运行的不同环境,会想要跟踪其他的一些性能指标,这些都是可以选择的。程序出现下面任何一种的情况,都表明可能存在问题,需要在最终发布前予以修正。
CPU 利用率
CPU使用的下降表明程序的性能有下降,这可能是由线程冲突问题引起的
在对CPU的用户使用时间与内核使用时间的比值进行监测时,请记住用户的使用时间应当占到CPU总使用时间80--90%这条规则。所以内核使用时间超过20%就意味着内核层的API调用指令有冲突。
为了让你对机器的投资有效地得到利用,应使CPU的利用率在负荷达到峰值时超过50%。如果低于这个值,表明在系统其他地方还有需要解决的瓶颈问题。