显示因浏览器思考时间或其他与客户端有关的延迟而使 客户机上的请求发生延迟时，所经过的平均时间。 显示从发出 HTTP 请求到返回错误消息（仅限于 HTTP 错误）这期间经过的平均时间。 也有可能你的程序中client的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:
首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.
%processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server可接受的最大上限是80% -85 %.也就是常见的CPU使用率.
%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%DPC time(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。 %Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Availiable bytes(memory):可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
Context switch/sec(system): (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
%Disk reads/sec(physicaldisk_total):每秒读硬盘字节数. %Disk write/sec(physicaldisk_total):每秒写硬盘字节数.
Page faults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Pages per second:每秒钟检索的页数。该数字应少于每秒一页
Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Avg.disk queue length:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。 Average disk read/write queue length: 指读取(写入)请求(列队)的平均数
Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average disk sec/read:以秒计算的在此盘上读取数据的所需平均时间。
Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Bytes total/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
Page write/sec:(写的页/秒)每秒执行的物理数据库写的页数。
1. 判断应用程序的问题
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.
从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的context switches/sec已经超过了15000.程序还是需要进一步优化.
2. 判断CPU瓶颈
如果processor queue length显示的队列长度保持不变(>=2)个并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.
3. 判断内存泄露问题
内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\\private bytes计数器和process\\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏
应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.
图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.
4．判断数据库资源情况
暂时只对Oracle数据库的资源分配情况进行讲解。今后会陆续补充上来。
1.如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache; select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存： select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。 缓冲区高速缓存命中率：
select name,value from v$sysstat where name in ('db block gets’, 'consistent gets','physical reads') ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets)) 3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = 'redo log space requests' ; 4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。 内存排序命中率 ： select
round((100*b.value)/decode((a.value+b.value),
0,
1,
(a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
