51Testing软件测试论坛

标题: 如何分析Analysis中各个图表的含义，写出性能测试报告 [打印本页]

作者: sbandbt 时间: 2005-10-26 13:43
标题: 如何分析Analysis中各个图表的含义，写出性能测试报告
如何分析Analysis中各个图表的含义，写出性能测试报告啊？请各位高手指点一下

作者: sbandbt 时间: 2005-10-26 14:52
自己顶一下~~~~~~~~

作者: iyaw 时间: 2005-10-28 16:58
去百度搜一下,很多如何分析性能瓶颈的文章

作者: sbandbt 时间: 2005-10-29 10:08
谢了，我搜了，没有找到，推荐一下那个网站吧

作者: sbandbt 时间: 2005-10-31 13:13
没有人回帖啊？自己再顶一下

作者: sendy 时间: 2005-10-31 13:32
呵呵，我给你顶一下！

作者: sbandbt 时间: 2005-10-31 15:01
还是你够意思。。。嘻嘻。。谢谢sendy了

作者: GIGI456 时间: 2005-10-31 16:54
有问题问斑竹阿，呵呵……

作者: xiaoqingting 时间: 2005-10-31 17:03
我也想问这个问题，给你顶一下！

作者: sbandbt 时间: 2005-11-1 09:29
呵呵。。。有道理

作者: nonway 时间: 2005-11-1 09:31
兄弟你的问题太大，很难有人可以回答你。你的问题有点类似loadrunner怎么用这样的问题。
呵呵自己慢慢去琢磨，遇到细点再来文

作者: sbandbt 时间: 2005-11-1 10:09
哦，那结果的分析图，那几个是比较重要的，他们的标准是什么啊？比如说他们的那些值是异常的，那些是正常的

作者: sbandbt 时间: 2005-11-1 10:10
还有有没有关于这方面的资料，给我上传一下下吧，这位兄台，呵呵

作者: linkage 时间: 2005-11-1 11:34
vuser数：
这个根据你选择的方案不同结果也不同，如果采用所有vuser同时运行，并且所有vuser都正确执行的话，这个图没什么用处。

平均事务响应时间：
这个应该是关注最多的，一般来说，这个图的理想曲线是这样(针对同时开始vuser)：开始增长较快，中期几乎不增长，后期逐渐下降(类似发动机输出曲线)。比较差的曲线例如：线性增长，波动较大的曲线

每秒事务数：
一般来说，在平均事务响应时间达到期望要求的时候，这个值越大越好(峰值)

Windows资源/Unix资源：
这些就要看你监控哪些东西了(CPU利用率，内存使用情况，高速缓冲命中情况等)，CPU利用率的话在跑vuser期间最好不要超过80%，否则就是资源瓶颈(我们做Weblogic+Oracle测试时，oracle主机cpu利用率没超过20%，而Weblogic主机cpu利用率在整个方案运行中期徘徊在90%左右，性能瓶颈在Weblogic中需要优化)

作者: 泓山巍水 时间: 2005-11-1 11:41
同意楼上的，我觉得每个图表在进行不同操作时都有不同的意义，测试不同功能时的关注信息也不同^_^

作者: sbandbt 时间: 2005-11-1 12:55
哦，真是受益匪浅，谢谢linkage

作者: sbandbt 时间: 2005-11-1 13:05
对于b/s架构的系统都需要关注那些性能指标呢？或是瓶颈通常在那里？

作者: wisebinbin 时间: 2005-11-1 13:45
受教育了，呵呵，性能的分析好像还得从经验中得来。

作者: sbandbt 时间: 2005-11-1 14:39
哎。。。关键是一开始是比较难啊

作者: linkage 时间: 2005-11-1 16:07
Web应用一般关注的性能指标：

平均事务响应时间
每秒事务数
主机资源(Unix/Windows)
数据库资源(Oracle/Sybase/DB2/MS SQL等)
应用服务器(WebLogic/WebSphere等)
网络情况(局域网的基本可以忽略，但如果存在专线/DDN/PSTN等广域网情况时需考虑延迟情况)

其实无论C/S还是B/S分析的东西都差不多。

排除网络瓶颈的话，问题一般按下顺序：Web服务器->应用服务器->数据库
具体的还是要看实际的监控情况才能给出响应的分析。

作者: sbandbt 时间: 2005-11-1 16:56
呵呵。。今天又学到了不少，谢谢linkage

作者: sbandbt 时间: 2005-11-2 16:35
那系统的瓶颈主要看那几方面？怎么进行判断是否是瓶颈啊？

作者: xiaoqingting 时间: 2005-11-3 16:27
不错，学了不少东西呢

作者: pierre0505 时间: 2005-11-28 15:27
learning^^^^^^

作者: shark_jr 时间: 2005-11-29 09:33
顶！

作者: chenxi8320 时间: 2005-11-29 16:19
学习中，继续关注中！

作者: mojinde 时间: 2005-11-29 17:32
哪位高手能找一两个图来加以说明,那样就再好不过了

作者: lydlx 时间: 2005-12-3 15:43
是阿,是阿,同意楼上的说法,偶也很想知道阿!~~~

作者: swordman 时间: 2005-12-9 18:17
我顶顶顶^^^^^^^^^^^^^^^^^^^^^^再顶 !!!

作者: 汉武非大帝 时间: 2005-12-21 14:28
支持一下

作者: faye 时间: 2006-1-4 18:12
怎么不去精华区看看
比如：如何分析我们的结果 analysis用户指南

作者: ldneliza 时间: 2006-4-25 10:38
顶一下

作者: tina123456 时间: 2006-5-10 14:02
如何分析我们的结果 analysis用户指南没发现这个贴子啊

作者: wawa133 时间: 2006-5-10 16:20
有啊。。。。我记得论坛里有analysis的用户指南，好像还是7.8中文版本的，呵呵。如果没有我可以上传

作者: tiannianyong 时间: 2008-3-17 15:17
标题: 如何分析Analysis中各个图表的含义
1：
vuser数：
这个根据你选择的方案不同结果也不同，如果采用所有vuser同时运行，并且所有vuser都正确执行的话，这个图没什么用处。

平均事务响应时间：
这个应该是关注最多的，一般来说，这个图的理想曲线是这样(针对同时开始vuser)：开始增长较快，中期几乎不增长，后期逐渐下降(类似发动机输出曲线)。比较差的曲线例如：线性增长，波动较大的曲线

每秒事务数：
一般来说，在平均事务响应时间达到期望要求的时候，这个值越大越好(峰值)

Windows资源/Unix资源：
这些就要看你监控哪些东西了(CPU利用率，内存使用情况，高速缓冲命中情况等)，CPU利用率的话在跑vuser期间最好不要超过80%，否则就是资源瓶颈(我们做Weblogic+Oracle测试时，oracle主机cpu利用率没超过20%，而Weblogic主机cpu利用率在整个方案运行中期徘徊在90%左右，性能瓶颈在Weblogic中需要优化)

排除网络瓶颈的话，问题一般按下顺序：Web服务器->应用服务器->数据库

2：
Memory：
内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes：可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
Page/sec：表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo

rivate Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。

Processor：
监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"

hysical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。

Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较

监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）

Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）

作者: ljonathan 时间: 2009-6-5 10:01
一开始，一个人确实有点难，慢慢摸索吧

作者: yxd2006 时间: 2011-7-26 16:20
关注中……

作者: 倾斜的太阳 时间: 2011-7-26 16:41
不同的系统，关注的测试点也不同，不过大部分的测试点也是相同的，比如机器资源等，具体的分析方法，还真不是一个或者两个帖子能搞定的，还是需要慢慢的去找，学习的，介绍下个人的思路：
1.学习基本的性能测试基础，网络、操作系统
2.使用loadrunner的帮助文件，查看每个监控项的具体的意思
3.分析自己需要测试的系统的特性，找出需要监控那些指标
4.在根据结果进行分析，一般的分析方法也是可以在lr的帮助文件中找到的

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)