性能测试过程概述

性能测试过程概述  

2012-05-03 14:29:25|  分类： 默认分类 |  标签： |字号大中小 

每个系统都肯定会对性能有要求，这些要求大致被分为3类：

1.   可接受的响应时间

2.   吞吐量和并发用户

3.   未来对性能增长要求

首先，我们先看一下性能测试的周期是怎样的：

一阶段、规划

规划这部分最核心的，我觉得是对用户行为的分析和剖析。因为这是为第二个环节建立可依据的标准。对用户行为的分析和剖析，大致分为以下3类。

、吞吐量和并发用户数设计目标

    获取这些数据的途径可以是：网站服务器的日志文件、系统监视数据、数据库活动监视数据、市场调研等等。调研出来的数据，可以按照功能点来进行划分，以便清楚的知道各个功能点的使用比率、使用次数/小时，由此来确定并发数和吞吐量的分布。

、性能增长分析

    这部分的数据可以是通过市场调研来预测的，也可以是通过之前的经验来下的定论，也可以通过系统运行一段时间以来，用户的增长速度来确定。通过对增长趋势的分析，同时考虑到特殊情况（如：特定节日，特定事件）对系统的冲击，可以适当增加用户的增长趋势。至于增长趋势持续的时间，可以按照实际情况而定，由此来定出系统最终的吞吐量和并发用户数。

、用户活动剖析

    分析用户活动，我常用的是以下的几种方法：

1)   通过在程序中写代码，把登录用户的相关信息（登录名、IP地址、访问页面、功能操作、停留时间。。。等等）记录在数据库中

2)   通过IIS日志来记录用户活动记录，然后再对IIS日志进行分析。这个过程当然少不了必备的工具，当前市面上的工具很多。诸如AWStats、Analog、Summary、Webalizer、WebTrends等。这些工具虽然都是现成的，但是有的配置复杂，有的功能不够强大和灵活。所以更多的是把IIS日志导入到SQL SERVER中，自行写查询语句进行分析，这样灵活简单。但是如果日志文件过大，或者数量众多的时候，这个方法稍微有点麻烦，所以我推荐使用另外一个工具Log Parser。对于这个工具的使用说明，我会在后面进行介绍。

二阶段、创建脚本、运行脚本

这个阶段，根据第一阶段的分析结果，对需要进行性能测试的场景录制脚本，再根据环境分析结果对脚本进行微调（例如：加入虚拟IP、创建多用户登录等，各类情况根据实际决定，这里不多说）。脚本调试好，在运行之前，打开各性能指标的计数器，SQL Server开启跟踪，然后运行脚本，并实时监控，以及手工N+1测试。

关于计数器，我常用的如下，不含特殊情况下需要用到的一些指标：

操作系统
性能对象	计数器对象	计数器	瓶颈条件	建议的效能调整方法	备注
内存	Memory	Pages/Sec	0 - 20（如果大于80，表示有问题）。	增加内存大小
		Available Mbytes	<100M	增加内存大小
		Pool Nonpaged Bytes	缓慢的增长表示存在内存泄漏,应该保持稳定
处理器	Processor	% Processor Time	<75%	升级处理器速度或增加处理器个数	如果有多个处理器，除了统计Total之外，最好每个处理器都要再单独统计一次
		% Interrupt Time			监视该计数器，来分析判断磁盘驱动器、网络适配器和其他能够产生中断的驱动器的活动情况
系统	System	Processor Queue Length	<2	升级处理器速度或增加处理器个数
硬盘	PhysicalDisk	Avg. Disk Read Queue Length	<2	1、换更快速的磁盘驱动器 2、数据库档案的档案群组重新规划分散于不同的磁盘阵列
		Avg. Disk Write Queue Length	<2	同上
IIS	Internet Information Services Global	File Cache Flushes
		File Cache Hits
		File Cache Hits %
	Web Service	Bytes Total/sec
		Current Connections
		Not Found Errors/sec

 

SQL Server
性能对象	计数器对象	计数器	瓶颈条件	建议的效能调整方法	备注
内存	SQLServer:Buffer Manager	Buffer cache hit ratio	< 90	增加内存大小
	SQLServer:Memory Manager	Target Server Memory (KB)	超过物理内存大小	同上
		Total Server Memory (KB)	> 70~80%	同上
数据库Tempdb	SQLServer:Database	Data File(s) Size (KB)	可以得知是否持续增加	见后面的解释
事务历史记录档		Log File(s) Size (KB)	10~25% Date File Size	备份或清除事务历史记录档，然后压缩文件案

 

ASP.NET
性能对象	计数器对象	计数器
系统性能计数器	ASP.NET (+版本号)	Application Restarts
		Request Wait Time
		Requests Queued
		Requests Rejected
应用程序性能计数器	ASP.NET Applications	Cache Total Turnover Rate
		Errors Total
		Request Execution Time
		Requests Failed
		Requests Not Authorizedd
		Requests Not Found
		Requests Timed Out
		Requests/Sec

三阶段、分析优化

    运行完脚本，关闭跟踪。接下来就是分析日志，分析跟踪结果了。这部分很复杂，涉及很多方面的知识。以B/S结构为例，整个网络的体系架构大致如下：

    

参照上图，我大致把整个过程的时间简单的分为以下的几部分：

客户端与服务器间的网络传输时间：T1+T7

服务器执行时间：T2+T4+T6

服务器间网络传输时间：T3+T5

客户端运行呈现时间：T8

当然并不是每次访问都是由这些时间相加，例如WEB和DB在同一台服务器，或者此次访问根本就没有对数据库进行访问。

对每个部分的时间都需要用不同的方法进行确认，初步分析出最耗时的环节进行优化。优化所需的技能和知识就多了，例如：你发现在内存不断减少，怀疑有内存泄漏，那么怎么判断是什么导致内存泄漏？某次访问的时候耗时很久，那么到底是哪部分耗时最久？当前系统所采用的技术是否是制约性能瓶颈？硬件是否是瓶颈，哪部分造成瓶颈？

优化需要大量的技能，是个需要不断的、长期的积累的过程。

路，还长的很啊。