码迷,mamicode.com
首页 > 其他好文 > 详细

性能测试-13.测试指标的判定标准总结

时间:2018-06-17 16:06:51      阅读:202      评论:0      收藏:0      [点我收藏+]

标签:缓冲   信息   在线用户   hits   原则   例子   估计   指标   友好   

 
响应时间:
  1.利用2-5-8原则去判定
吞吐量:
  1.125*x kb/s*0.5,若小于前面的数值为优,其中x为x Mb/s,例如1 Mb/s
每秒点击数:
  1.指客户端每秒钟向服务器端提交的请求数量,如果客户端发出的请求数量越多,与之相对的平均吞吐量也应该越大
并发用户数:
  1)、经典公式1:
     一般来说,利用以下经验公式进行估算系统的平均并发用户数和峰值数据
      1)平均并发用户数为 C = nL/T
      2)并发用户数峰值 C‘ = C + 3*根号C
        C是平均并发用户数,n是login session的数量,L是login session的平均长度,T是值考察的时间长度
        C’是并发用户数峰值
举例1,假设系统A,该系统有3000个用户,平均每天大概有400个用户要访问该系统(可以从系统日志从获得),对于一个典型用户来说,一天之内用户从登陆到退出的平均时间为4小时,而在一天之内,用户只有在8小时之内会使用该系统。
  那么,
      平均并发用户数为:C = 400*4/8 = 200
        并发用户数峰值为:C‘ = 200 + 3*根号200 = 243
举例2, 某公司为其170000名员工设计了一个薪酬系统,员工可进入该系统查询自己的薪酬信息,但并不是每个人都会用这个系统,假设只有50%的人会定期用该系统,这些人里面有70%是在每个月的最后一周使用一次该系统,且平均使用系统时间为5分钟。则一个月最后一周的平均并发用户数为(朝九晚五):
      n = 170000*0.5*0.7/5 = 11900
      C= 11900*5/60/8 = 124
      吞吐量计算为:F = Vu * R / T 单位为个/s
         F为事务吞吐量,Vu为虚拟用户数个数,R为每个虚拟用户发出的请求数,T为处理这些请求所花费的时间
  2)、通用公式2:
    对绝大多数场景,我们用(用户总量/统计时间)*影响因子(一般为3)来进行估算并发量。
    比如,以乘坐地铁为例子,每天乘坐人数为5万人次,每天早高峰是7到9点,晚高峰是6到7点,根据8/2原则,80%的乘客会在高峰期间乘坐地铁,则每秒 到达地铁检票口的人数为50000*80%/(3*60*60)=3.7,约4人/S,考虑到安检,入口关闭等因素,实际堆积在检票口的人数肯定比这个要 大,假定每个人需要3秒才能进站,那实际并发应为4人/s*3s=12,当然影响因子可以根据实际情况增大!
  3)、根据PV计算公式:
    比如一个网站,每天的PV大概1000w,根据2/8原则,我们可以认为这1000w pv的80%是在一天的9个小时内完成的(人的精力有限),那么TPS  为:
    1000w*80%/(9*3600)=246.92个/s,取经验因子3,则并发量应为:
    246.92*3=740
  4)、根据TPS估计:
     公式为 C = (Think time + 1)*TPS
  5)、根据系统用户数计算:
     并发用户数 = 系统最大在线用户数的8%到12%
资源使用率:
  1).平均事务响应时间
  Average Transation Response Time优秀:<2s
  良好:2-5s
  及格:6-10s
  不及格:>10s
  2).每秒点击率
  Hits per Second
  当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈大体一致,则系统基本稳定若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,很可能是网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.
  3).请求响应时间
  Time to Last Byte
  4).每秒系统处理事务数
  Transaction per second
  5).吞吐量
  Throughout
  6).CPU利用率
  Processor/%Processor Time好:70%
  坏:85%
  很差:90%+
  7).数据库操作消耗的CPU时间
   Processor/%User Time如果该值较大,可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器,Processor\%User Time值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,此时可以考虑对数据库系统进行优化。
  8).核心态CPU平均利用率
  Processor/%Privileged Time如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统
  9).处理列队中的线程数
   Processor/Processor Queue Length如果该值保持不变(>=2)个并且%Processor Time超过90%,那么可能存在处理器瓶颈。如果发现超过2,而处理器的利用率却一直很低,那么或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶 颈。
  10).文件系统缓存
  Memory/Cache Bytes 50%的可用物理内存
  11).剩余的可用内存
  Memory/Avaiable Mbytes至少要有10%的物理内存值
  本文出自51Testing软件测试网,感谢会员fmsbai5在每周一问(08-12-29)中的精彩回答。http://bbs.51testing.com/forum-157-1.html
  12).每秒下载页数
  Memory/pages/sec好:无页交换
  坏:CPU每秒10个页交换
  很差:更多的页交换
  13).页面读取操作速率
  Memory/page read/sec如果页面读取操作速率很低,同时%Disk Time和Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
  14).物理磁盘利用率
  Physical Disk/%Disk Time好:<30%
  坏:<40%
  很差:<50%+
  15).物理磁盘平均磁盘I/O队列长度
  Physical Disk/Avg.Disk Queue Length该值应不超过磁盘数的1.5~2倍。要提高性能,可增加磁盘
  16).网络吞吐量
  Network Interface/Bytes Total/sec判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽,结果应该小于50%
  17).数据高速缓存区命中率命中率应大于0.90最好
  18).共享区库缓存区命中率命中率应大于0.99
  19).监控SGA中字典缓冲区的命中率命中率应大于0.85
  20)检测回滚段的争用小于1%
  21).监控SGA中重做日志缓存区的命中率
  应该小于1%
  22).监控内存和硬盘的排序比率最好使它小于10%

性能测试-13.测试指标的判定标准总结

标签:缓冲   信息   在线用户   hits   原则   例子   估计   指标   友好   

原文地址:https://www.cnblogs.com/cmnz/p/9192972.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!