基于Windows下的Web性能测试和压力测试文档格式.docx
《基于Windows下的Web性能测试和压力测试文档格式.docx》由会员分享，可在线阅读，更多相关《基于Windows下的Web性能测试和压力测试文档格式.docx（22页珍藏版）》请在冰点文库上搜索。
*SuccessfulRounds：
成功的请求；
*FailedRounds：
失败的请求；
*SuccessfulHits：
成功的点击次数；
*FailedHits：
失败的点击次数；
*HitsPerSecond：
每秒点击次数；
*SuccessfulHitsPerSecond：
每秒成功的点击次数；
*FailedHitsPerSecond：
每秒失败的点击次数；
*AttemptedConnections：
尝试链接数；
3、数据库服务器指标：
*User0Connections：
用户连接数，也就是数据库的连接数量；
*Numberofdeadlocks：
数据库死锁；
*ButterCachehit：
数据库Cache的命中情况；
上面的指标只是一些通用的指标，起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。
对于这些指标的详细了解，你可以参考Windows下面的SystemMonitor的帮助与LoadRunner、ACT的帮助。
对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。
对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner、ACT、WAS、WebLoad各个工具有它的使用范围；
其中我各个认为：
LoadRunner最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任；
WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试；
ACT则是与.NET集成比较好，支持ViewState（.NET下控件缓存的支持）的测试。
在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阈值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阈值的与一些通用参数有问题的子系统进行深入分析。
比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。
这个我们要对子系统进行详细测试，由于B/S结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行：
一、非程序部分，即图片等等；
二、应用程序本身。
通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。
对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常、死锁、网络流量等等前面没有注意到的情况的增加；
同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个。
刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。
最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。
上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。
下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：
一、性能达不到目标；
二、性能达到目标，但有一些其它的问题，比如异常、死锁。
缓存命中过低，网络流量较大；
三、服务器稳定性的问题，比如内存泄漏……。
要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify，主要是他对.net与java、C++都有支持，而且分析效果特别专业。
我们先了解一下RationalPurify。
RationalPurify能自动找出VisualC/C++和Java代码中与内存有关的错误，确保整个应用程序的质量和可靠性。
在查找典型的VisualC/C++程序中的传统内存访问错误，以及Java，C#代码中与垃圾内存收集相关的错误方面；
RationalQuantity则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。
我们先说性能优化与异常的处理，性能优化有一个原则——即用时间比例最大的进行优化，效果才最明显。
比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒，提升了29.7秒；
而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显而且写过程序的人都知道，后者性能优化的代价更大。
在性能优化的过程中，一般是先数据库，后程序。
因为数据库的优化不需要修改程序，修改的风险很小。
但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数，这时你就需要分析数据库，呵呵。
数据库的分析原则是先索引，后存储过程，最后表结构视图的优化。
索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。
在这里我要给大家简单的介绍一下我的最爱：
SQLProfile、SQL查询分析器。
PreciseSQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。
同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。
数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事。
测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。
内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++内存问题比较多，Java与.NET比较少，一般由GC不合理引起。
C++的内存错误就比较多了，主要常见的有:
1、ArrayBoundsRead（ABR）：
数组越界读
2、ArrayBoundsWrite（ABW）：
数组越界写
3、BeyondstackRead（BSR）：
堆栈越界读
4、FreeMemoryRead（FMR）：
空闲内存读
5、InvalidpointerRead（IPR）：
非法指针阅读
6、NullPointerRead（NPR）：
空指针阅读
7、UninitializedMemoryRead（UMR）：
未初始化内存读写
8、MemoryLeak：
内存泄漏
注：
如果需要更多的信息，可以参见Purify的帮助信息。
顺便提一句，为什么我要说做单元测试时做内存分析比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage来做就更完美了。
本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍，你也可使用你比较熟悉的工具达到相同的目标。
性能管理
说到Windows环境下的性能管理，许多人首先想到的可能就是无处不在的PerformanceMonitor工具。
早在WindowsNT时代，PerformanceMonitor就是获取性能信息的主要工具，当然，任务管理器和Windows管理规范（WindowsManagementInstrumentation）也属于常用工具之列，它们不仅能够提供性能数据，而且还能提供其他与性能有关的管理信息。
本文介绍了一些充分发挥这些经典工具潜能的技巧，同时介绍了WindowsXP新增的工具，探讨如何运用它们来评估系统的性能情况。
一、什么是性能管理？
对于许多管理员来说，Windows的性能管理不外乎打开控制面板→管理工具中的“性能”程序，即PerformanceMonitor程序，然后检查一下CPU利用率、磁盘忙闲状况、内存压力，而且通常只有在出现性能问题时才会去检查，例如服务器响应突然变慢，或者用户不能访问服务器。
这种性能管理方式完全属于事后补救的方式，只起到了救火队员的作用，由于缺乏详尽、明确的事前评估、规划，算不上优秀的策略。
要实现有效的性能管理，一定要在出现问题之前掌握系统的性能情况。
只有事先采取有效的性能管理策略，才能全面掌握系统的性能特征，在此基础上，就可以估计何时可能出现性能问题以及问题的具体表现。
预先收集的性能数据还可以用来规划未来的运算能力需求，例如，假设有一个IISWeb服务器，当并发用户数量是200时CPU的利用率是60%，据此可以推断系统负载何时达到极限，以及达到负载极限时能够支持的并发用户数量。
另外，根据网站的增长情况，还可以估计出何时需要增添硬件设备。
系统的整体性能由许多因素决定，例如CPU利用率，CPU队列长度（即，有多少任务正在等待CPU的服务），磁盘忙闲程度（即，磁盘驱动器有多少时间用于响应请求），可用的物理内存，网络接口的利用情况，等等，表一概括了最常用的性能计数器。
表一：
重要的性能计数器
性能对象
计数器
提供的信息
Memory
AvailableBytes
AvailableBytes显示出当前空闲的物理内存总量。
当这个数值变小时，Windows开始频繁地调用磁盘页面文件。
如果这个数值很小，例如小于5MB，系统会将大部分时间消耗在操作页面文件上。
%CommittedBytesinUse
%CommittedBytesInUse是Memory:
CommittedBytes与Memory:
CommitLimit之间的比值。
（Committedmemory指如果需要写入磁盘时已在分页文件中保留空间的处于使用中的物理内存。
CommitLimit是由分页文件的大小而决定的。
如果扩大了分页文件，该比例就会减小）。
这个计数器只显示当前百分比；
而不是一个平均值。
PageFaults/sec
PageFaults/sec是指处理器处理错误页的综合速率。
用错误页数/秒来计算。
当处理器请求一个不在其工作集（在物理内存中的空间）内的代码或数据时出现的页错误。
这个计数器包括硬错误（那些需要磁盘访问的）和软错误（在物理内存的其它地方找到的错误页）。
许多处理器可以在有大量软错误的情况下继续操作。
但是，硬错误可以导致明显的拖延。
这个计数器显示用上两个实例中观察到的值之间的差除以实例间隔的持续时间所得的值。
NetworkInterface
BytesTotal/sec
BytesTotal/sec是发送和接收字节的速率，包括帧字符在内。
Packets/sec
Packets/sec为发送和接收数据包的速率。
PhysicalDisk
%BusyTime
%BusyTime指磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
Avg.DiskQueueLength
Avg.DiskQueueLength指读取和写入请求（为所选磁盘在实例间隔中列队的）的平均数。
CurrentDiskQueueLength
CurrentDiskQueueLength指在收集操作数据时在磁盘上未完成的请求的数目。
它包括在快照内存时正在为其提供服务中的请求。
这是一个即时长度而非一定间隔时间的平均值。
多主轴磁盘设备可以一次有多个请求操作，但是其它同时发生的请求为等候服务。
这个计数器可能会反映一个暂时的高或低的列队长度，但是如果在磁盘驱动器存在持续负载，可能值会总是很高。
请求等待时间与这个列队的长度减去磁盘上的主轴成正比。
这个差值应小于2才能保持良好的性能。
Processor
%ProcessorTime
%ProcessorTime指处理器执行非闲置线程时间的百分比。
这个计数器设计成用来作为处理器活动的主要指示器。
它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。
（每个处理器有一个闲置线程，该线程在没有其它线程可以运行时消耗周期）。
可将其视为范例间隔用于做有用工作的百分比。
%UserTime
%UserTime指用于用户模式的非闲置处理器时间的百分比（用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。
另一个模式为特权模式，它是为操作系统组件设计的并且允许直接访问硬件和所有内存。
操作系统将应用程序线程转换成特权模式以访问操作系统服务）。
这个计数值将平均忙时作为实例时间的一部分显示。
ServerWorkQueues
QueueLength
QueueLength指CPU当前的服务器作业队列长度。
队列长度长时间超过四可能表示处理器堵塞。
此值为即时计数，不是一段时间的平均值。
System
ProcessorQueueLength
ProcessorQueueLength是指处理队列中的线程数。
即使在有多个处理器的计算机上处理器时间也会有一个单队列。
不象磁盘计数器，这个计数器仅计数就绪的线程，而不计数运行中的线程。
如果处理器队列中总是有两个以上的线程通常表示处理器堵塞。
这个计数器仅显示上一次观察的值；
TCP
SegmentsRetransmitted/sec
SegmentsRetransmitted/sec指程序段重新传输的速率，即传输的程序段中包含一个或多个以前传输过的字节。
二、定制性能监视器
在Windows2K/XP中，PerformanceMonitor仍是最常用的性能管理工具。
当然，新版的工具不少地方已经改进，增添了不少功能。
在Win2K中，性能监视器以一个管理控制台（MMC）单元的形式实现。
启动Win2K/XP的性能监视器，可以看到类似图一的界面。
图一
在WinXP中，性能监视器默认装入三个计数器：
Pages/sec，Avg.DiskQueueLength，%ProcessorTime。
这三个计数器无法直接删除，但一直留着又降低了监视器启动速度。
如果要让监视器启动时不装入任何计数器。
（让监视器启动时不装入任何计数器）首先要清除\%systemroot%\system32目录下perfmon.msc文件的只读属性：
进入命令窗口，转到system32目录，执行命令attribrperfmon.msc。
然后重新启动计数器，选中一个计数器，点击工具栏上黑色的“X”按钮即可删除一个计数器。
选择菜单“文件”→“保存”，将更改后的管理控制台保存到磁盘。
如果要将管理控制台执行标记成只读，只需在命令行上执行attrib+rperfmon.msc即可。
在NT4.0中，性能监视器包含一个实时图表，另外还有记录日志和报警功能，但在Win2K和XP的中，这些功能分开了。
在Win2K/XP中，实时性能图表变成了“系统监视器”，系统监视器之下是日志和警报工具。
系统监视器可以看作一个纯粹的实时性能数据察看工具，只能看，不能保存，点击工具栏上的“+”按钮可以添加新的性能计数器。
性能日志和警报工具则具有操作历史数据的功能。
如果要创建一个只有系统监视器、不带性能日志和警报工具的管理控制台，可按如下步骤操作：
执行“MMC”命令，打开一个空白的MMC窗口，选择菜单“文件”→“添加/删除管理单元”，点击“添加”，选择“ActiveX控件”，再点击“添加”，在向导中选择SystemMonitorControl，确认即可。
三、性能日志和警报工具
系统监视器只能简单地查看实时性能数据，如果需要长期的、持久化的性能数据，必须使用性能日志和警报工具。
性能日志工具能够在一个日志文件中集中记录来自本地或远程的多个系统的性能数据，这些日志数据可以用系统监视器查看或用其他工具处理。
扩展控制台中的“性能日志和警报”节点，可以看到它的三个分支：
计数器日志，跟踪日志，警报。
警报工具的功能很简单，就是当某个计数器的性能数据达到指定的值时，执行一定的动作，例如发送Email或用NetSend命令发送消息。
下面我们主要讨论的是日志工具。
为了说明如何使用计数器日志，我们要新建一个日志会话。
右击“计数器日志”节点，选择“新建日志设置”，指定日志设置的名称，点击“确定”，出现图二的对话框，在这里设定要在日志中记录的计数器。
图二
日志文件的默认保存路径是C:
\perflogs目录，可以在对话框的“日志文件”页修改，但首先要设置待记录的对象和计数器才能转到“日志文件”页。
点击“添加对象”按钮，将某个监视对象的所有计数器加入日志记录，或者点击“添加计数器”按钮加入单个计数器。
无论选择哪种加入选项，监视目标（对象或计数器）都可以是本地的，也可以是远程机器的。
如果要长期收集性能数据，最好调整一下采样间隔时间——特别地，如果要监视的计数器很多，而且来自不同的机器，如果采样间隔时间设置得太小，日志文件很快会变得很大。
从每隔15分钟采样一次开始，试运行一段时间，看看日志文件变得多大了，然后再作相应的调整。
如果要连接远程机器，可以在“运行方式”输入框提供登录远程机器的用户名字。
收集性能监视数据需要一定的权限，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Perflib注册子键控制着对性能监视数据的访问，性能监视数据正是通过该注册子键流到系统监视器之类的工具。
用右键点击该注册子键，选择菜单“权限”，如图三，调整这里的权限分配也就调整了有权访问性能数据的用户。
图三
设置好要监视的对象和计数器之后，可以在“日志文件”页调整日志文件的格式，在“计划”页设置启动、停止日志的时间。
如果设置成手工启动，启动方式是在MMC窗口中右击日志会话并选择“启动”。
在“日志文件”页中，如图四，性能计数器日志除了默认的二进制.blg格式之外，还可以保存为其他多种格式，例如逗号分隔的文本文件（即CSV文件），甚至还可以保存到SQLServer表——这是WindowsServer2003和XP才有的功能。
如果选择了SQLServer，还要指定一个SQLServer数据源和保存数据的表，虽然麻烦一点，不过如果要收集大量的性能数据并进行分析，SQLServer还是一种不错的选择。
图四
启动日志之后，可以看到日志目录中生成了一个65KB的日志文件。
每次关闭和重新启动日志，都会生成一个新的日志文件，文件名字中的序号依次增加。
WinXP和2K支持一项非常实用的功能，即使在性能监视器工具不运行的时候，也能继续将性能数据写入日志。
如果是NT4.0，则需要安装NT4.0ResourceKit的DataLog服务才能使用这个无人值守日志记录功能。
Win2K和XP本身就有PerformanceLogsandAlerts服务，该服务在日志会话启动时自动启动，日志会话结束时自动停止。
Win2K/XP性能日志的另一个改进之处是保存日志会话功能。
在NT4.0中，如果要为某个日志会话重新使用一组选定的性能对象和计数器，必须为每一台想要监视的服务器重新创建工作台文件，如果要将一组日志配置分别在多台服务器上本地运行，必须重复执行繁琐的配置操作。
但在Win2K/XP中，所有配置文件（包括日志和警报）都以HTML文件的形式保存，很容易修改和重用。
要保存一个日志会话配置，只要在MMC窗口中右击会话，然后选择菜单“将设置另存为”即可。
四、命令行工具
XP提供了一个叫做Logman的新工具，它不仅能够在命令行上启动和停止日志会话，而且能够从命令行创建新的日志会话。
例如，下面的第一Logman命令新建了一个iislogging会话，日志文件保存在默认c:
\perflogs\IISLogging.blg，日志中加入了本地服务器上inetinfo.exe进程的Process\%ProcessorTime计数器，收集性能数据的时间间隔是15分钟。
第二个命令启动了iislogging日志会话。
运行这些命令之后，如果启
升级会员 