本文共 7735 字,大约阅读时间需要 25 分钟。
1、前言很明显大多数事务的响应时间在60-140S。在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右。140S的时间很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表,我们不难看到此系统在这种环境下并不理想。世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析。 系统性能不好的原因多方面,我们先从应用程序看,有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因。先看一张页面细分图。一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下。图片中显示了整个测试过程中涉及到的所有web页。web page breakdown中显示的是每个页面的下载时间。点选左下角web page breakdown展开,可以看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性。在select page to breakdown中选择页面。见图。
在Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks后,在下方看到属于它的两个组件,第一行中Connection和First Buffer占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手。
名称 | 描述 |
显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地 址所需的时间。“DNS 查找”度量是指示 DNS 解析问 题或 DNS 服务器问题的一个很好的指示器。 | |
显示与包含指定 URL 的 Web 服务器建立初始连接所需 的时间。连接度量是一个很好的网络问题指示器。此 外,它还可表明服务器是否对请求作出响应。 | |
显示从初始 HTTP 请求(通常为 GET)到成功收回来 自 Web 服务器的第一次缓冲时为止所经过的时间。第 一次缓冲度量是很好的 Web 服务器延迟和网络滞后指 示器。 注意:由于缓冲区大小最大为 8K,因此第一次缓冲时 间可能也就是完成元素下载所需的时间。 | |
显示建立 SSL 连接(包括客户端 hello、服务器 hello、客户端公用密钥传输、服务器证书传输和其他 部分可选阶段)所用的时间。自此点之后,客户端与服 务器之间的所有通信都将被加密。 SSL 握手度量仅适用于 HTTPS 通信。 | |
显示从服务器收到最后一个字节并完成下载之前经过的 时间。 “接收”度量是很好的网络质量指示器(查看用来计算 接收速率的时间/ 大小比率)。 | |
显示验证客户端所用的时间。如果使用 FTP,则服务器 在开始处理客户端命令之前,必须验证该客户端。 “FTP 验证”度量仅适用于 FTP 协议通信。 | |
显示因浏览器思考时间或其他与客户端有关的延迟而使 客户机上的请求发生延迟时,所经过的平均时间。 | |
显示从发出 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的值会降低。内存泄漏应该通过一个长时间的用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验。图中可以看到该程序并不存在内存泄露的问题,内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽。也是提醒大家对系统稳定性测试的关注。
附件:
CPU信息:----------------------------------------------------------------------------------------------------------------
转自:http://bbs.51testing.com/viewthread.php?tid=77363&highlight=%B2%E2%CA%D4%BD%E1%B9%FB%B7%D6%CE%F6 作者:姜全尧
转载地址:http://cwtxi.baihongyu.com/