每个系统都肯定会对性能有要求，这些要求大致被分为3类：
1. 可接受的响应时间
2. 吞吐量和并发用户
3. 未来对性能增长要求
首先，我们先看一下性能测试的周期是怎样的：
一阶段、规划
规划这部分最核心的，我觉得是对用户行为的分析和剖析。因为这是为第二个环节建立可依据的标准。对用户行为的分析和剖析，大致分为以下3类。
1.1、吞吐量和并发用户数设计目标
获取这些数据的途径可以是：网站服务器的日志文件、系统监视数据、数据库活动监视数据、市场调研等等。调研出来的数据，可以按照功能点来进行划分，以便清楚的知道各个功能点的使用比率、使用次数/小时，由此来确定并发数和吞吐量的分布。
2.2、性能增长分析
这部分的数据可以是通过市场调研来预测的，也可以是通过之前的经验来下的定论，也可以通过系统运行一段时间以来，用户的增长速度来确定。通过对增长趋势的分析，同时考虑到特殊情况（如：特定节日，特定事件）对系统的冲击，可以适当增加用户的增长趋势。至于增长趋势持续的时间，可以按照实际情况而定，由此来定出系统最终的吞吐量和并发用户数。
2.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、换更快速的磁盘驱动器 |
|
|
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在同一台服务器，或者此次访问根本就没有对数据库进行访问。
对每个部分的时间都需要用不同的方法进行确认，初步分析出最耗时的环节进行优化。优化所需的技能和知识就多了，例如：你发现在内存不断减少，怀疑有内存泄漏，那么怎么判断是什么导致内存泄漏？某次访问的时候耗时很久，那么到底是哪部分耗时最久？当前系统所采用的技术是否是制约性能瓶颈？硬件是否是瓶颈，哪部分造成瓶颈？
优化需要大量的技能，是个需要不断的、长期的积累的过程。
路，还长的很啊。
