如果你有坚定的信念你就不会迷茫。

性能测试-修改版理发师模型

上一篇 / 下一篇  2010-10-13 13:46:49 / 个人分类:性能测试

最近在做性能测试相关的内容,有小点感悟。顺便把理发店的例子看看了觉得很好,修改了一下然后放出来大家共享下。

性能测试主要是通过自动化的测试工具模拟系统负载,以确定系统的处理能力,并通过对CPU、内存、磁盘IO、带宽等性能指标的关注发现系统瓶颈,提高系统容量。性能测试通常包括负载测试和压力测试两种,前者主要衡量负载能力系统的处理能力,主要关注数据包括请求/秒、系统响应时间等,后者主要衡量在负载出现浪涌这样的极限情况下,系统本身会不会崩溃掉,主要关注系统本身的性能指标。

首先介绍一下性能测试中常用的几个基本概念:

l 并发数:对于服务器来说并发数就是在同一时间处理请求的总线程数量。我们服务器IIS的默认最大线程数是200。也就是说当客户端负载大于200时,服务器的并发数量就不会随之增加了。

l 请求/秒:即每秒钟服务器处理的客户端请求数量,体现了服务器处理请求的能力

l 响应时间:及服务器处理每个请求所消耗的时间,在Ezhometools客户端计算出的响应时间是从客户端发起一个请求开始到客户端接收到服务器的返回响应结束的整个过程所耗费的时间。

在系统并发数少时,每个并发获得的资源多,此时响应速度快,单个并发在同样的时间内能处理的请求就多,但是由于并发少时,如单线程处理时,大量的处理时间是浪费在了磁盘IO这样的操作上,CPU被闲置。因此,一定范围内增加并发,可以使系统实际处理的请求增加。当并发增加到一定程度时,响应时间增大,能处理的请求/秒将达到峰值。因此,好的系统,请求/秒达到顶点的时候,也将是CPU能力耗尽的时候。由此可知:请求/=并发/响应时间

我们最终要收集并呈现出来的图表,应该包括CPUmemory、请求/秒、response time等与并发的关系。通过性能测试,同样可以测试出什么样的并发数对系统是最合理的。

1、 服务器处理请求能力的拐点,以此来评估系统的能力

通过不断的增加客户端的请求数量,查看服务器处理请求的能力在什么时候开始下降(Request/Sec),此时每个请求的平均Response Time会在该拐点处加速增加。

如下图中蓝色的线是Response Time,绿色的线是Request/Sec。可以看到在并发数量达到50时,Response Time加速增长,同时Request/Sec即每秒处理请求的能力降低了。也就是说服务器处理该接口最多可处理306 Request/Sec

由此可知我们需要通过收集被测接口不同的并发数量下服务器的Response Time, Request/Sec的值,通过这些值的趋势来判断服务器处理请求的能力。

2、 观察CPUMemory等性能指标识别系统中的弱点

当服务器处理请求过程中,我们需要收集CPU, Memory的情况。查看CPU, Memory的占用率是否在正常的范围内(通常需要低于70%)。

3、 验证系统稳定性

l 通过查看CPUMemory的波动图,例如:如果平均的CPU占用率为30%,但是常常会有一些时间段CPU占用率达到90%以上,那么系统的稳定性就不够。

l 查看请求执行的成功率,这个可以通过客户端来查看。

我们假设一个理发店有如下条件:

1.理发店共有3名理发师;

2.每位理发师剪一个发的时间都是1小时;

通过上面的假设我们不难想象出下面的场景:

1.当理发店内只有1位顾客时,只需要有1名理发师为他提供服务,其他两名理发师可能继续等着,有时会帮忙正在理发的理发师打杂,因为有其他理发师打杂该顾客理发时间小于1个小时,可能是0.5小时。此时,客户端负载为=1,服务器端的并发数=1,响应时间= 0.8小时,理发店的处理能力是每小时1/0.8=1.25位顾客。

2.当理发店内同时有2位顾客时,就会同时有2名理发师在为顾客服务,另外1位继续等待或者打杂帮忙。因为只有一个理发师帮其他两位理发师打杂,那么这2位顾客可能需要0.8小时完成理发。此时,客户端负载为=2,服务器端的并发数=2,响应时间= 0.9小时,理发店的处理能是每小时2/0.9=2.22位顾客。

3.当理发店内同时有3位顾客时,理发店可以在1小时内同时服务三位顾客,每位顾客花费

的时间均为1小时。此时,客户端负载为=3,服务器端的并发数=3,响应时间= 1小时,理发店的处理能是每小时3/1=3位顾客。

从上面几个场景中我们可以发现,在理发店同时服务的顾客数量从1位增加到3位的过程中,随着顾客数量的增多,理发店的整体工作效率在提高(请求/小时从1.25增长到3)。

 

4.当理发店同时有6位顾客时,每剪完3位就会再来3位顾客来等待。那么,只有前3位顾客需要1个小时剪发,后面3位顾客以及新进理发的所有顾客都需要2小时才能完成剪发(等待1个小时+剪发1个小时)。此时,客户端负载为=6,客户端请求响应时间=2(客户端的响应时间需要计算等待时间),服务器端的并发数=3,响应时间= 1小时(服务器端的响应时间不计算队列等待时间),请求/小时= 3/1 = 3

从上面场景中我们可以发现,在理发店同时服务的顾客数量从3位增加到6位的过程中,随着顾客数量的增多,理发店的整体工作效率并没有提高,仍然是3

 

5.当理发店同事有15位顾客时,也就是说同时有十几位顾客在等待,这个时候理发师在理发的同事需要抽身出来帮助安排外面排队的人,比如叫号、处理插队事件、给你端茶等等。每位顾客需要超过一个小时时间剪发,假设是1.2小时,此时,客户端负载为=15,客户端请求响应时间=5*1.2,服务器的并发数=3,服务器的响应时间= 1.2小时,请求/小时= 3/1.2 = 2.5

从上面场景中我们发现,在理发店同时服务数量增加到20的过程中,随着顾客的增多,理发店的整体工作效率却降低了,从3变成2.5了。

 

这张图中展示的是标准的软件性能模型。在图中有三条曲线,分别表示资源的利用情况(Utilization,包括硬件资源和软件资源)、吞吐量(Throughput,这里是指请求/秒)以及响应时间(Response Time)。图中坐标轴的横轴从左到右表现了并发用户数(Number of Concurrent Users)的不断增长。在这张图中我们可以看到,最开始,随着并发用户数的增长,资源占用率和吞吐量会相应的增长,但是响应时间的变化不大(同理发店的场景123);不过当并发用户数增长到一定程度后,资源占用达到饱和,吞吐量增长明显放缓甚至

停止增长,而响应时间却进一步延长(同理发店场景4)。如果并发用户数继续增长,你会发现软硬件资源占用继续维持在饱和状态,但是吞吐量开始下降,响应时间明显的超出了用户可接受的范围(同理发店场景5)。

根据这种性能表现,图中划分了三个区域,分别是Light Load(较轻的压力)、Heavy Load(较重的压力)和Buckle Zone(用户无法忍受并放弃请求)。在Light LoadHeavy Load两个区域交界处的并发用户数,我们称为“最佳并发用户数(The Optimum Number of Concurrent Users)”,而Heavy LoadBuckle Zone两个区域交界处的并发用户数则称为“最大并发用户数(The Maximum Number of Concurrent Users)”。当系统的负载等于最佳并发用户数时,系统的整体效率最高,没有资源被浪费,用户也不需要等待;当系统负载处于最佳并发用户数和最大并发用户数之间时,系统可以继续工作,但是用户的等待时间延长,满意度开始降低,并且如果负载一直持续,将最终会导致有些用户无法忍受而放弃;而当系统负载大于最大并发用户数时,将注定会导致某些用户无法忍受超长的响应时间而放弃。


TAG: 理发店模型 性能测试

jarystar的个人空间 引用 删除 jarystar   /   2011-03-15 17:13:35
5
 

评分:0

我来说两句

日历

« 2024-04-23  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 20078
  • 日志数: 19
  • 建立时间: 2010-09-08
  • 更新时间: 2011-01-21

RSS订阅

Open Toolbar