qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

从食堂就餐看性能测试分析

 中午在单位食堂吃饭排了个长队,等了好半天。然后就想这不就是在跑性能吗??

  如果把食堂看作一个在线系统,员工吃饭看作是一次业务处理。回过头来看系统性能测试分析中需要关注的点,其实颇有意思

  首先最直观的性能表现就是打饭窗口的长队,可以说这是系统性能处理能力最直观的表现了。指标对应ResponseTime

  队伍前进的快慢,对应每秒处理事务数TPS

  同时进餐人数,对应并发请求数

  我们再看看影响性能指标的相关因素

  1)打饭窗口数--对应业务处理进程数,有时某个窗口存在多个打饭师傅,这时可以看作是多线程。处理进程(线程)的多少,是决定业务处理性能的最主要因素。

  2)师傅的业务熟练程度--处理器的性能,计算能力

  3)所点餐品多少和分布情况--对应数据的处理能力。所点餐品离窗口近,分布集中,自然处理起来快些,好比数据存储在内存库,不进行跨表、跨库的关联处理之类,性能自然较好。

  4)刷卡付账环节--一般组合的餐品价格师傅都能快速算出来,但是比较多的菜品,计算起来要多花点时间。好比对于一些常见的请求,从缓存里读取自然会快些。

  异常情况1:卡内金额不够、点菜结束又再点了一份。对应到这些异常处理或是重试会也影响处理性能。

  异常情况2:看菜单上有的菜,点菜时却发现没有,需要重新确认。这个相当于业务请求先查询出携带的参数,响应却判参数不存在了。数据实时关联没做好,属于系统Bug(此Bug还存在啊)

  5)选择的餐品类型---打饭的队伍比等面条、馄饨的队伍处理起来一般相对快些。不同业务,处理的方式不同,性能表现也不同。

  另外,餐厅的面积是有限的,窗口数也是有限的,打饭师傅的数量也是有限的。所以系统处理能力或曰系统容量是有限的。貌似目前食堂还没达到处理极限(虽然用户满意度不高),暂时还不用扩容,呵呵

  其实我们注意到,针对处理能力的问题,有两个现象:

  1)二楼食堂人满为患,一楼食堂比较宽松。这个给我们的启示就是,在系统还具备处理能力的前提下,性能并不是影响用户选择的最主要参考(关键需求即业务本身的吸引力更重要)。但系统超过处理能力或者系统异常,无法提供服务后果还是很严重的。饿肚子咋干活。。

  2)业务上存在分时处理,所有的业务请求被强制分时间段访问。这个是根据业务特点决定的,业务具有明显的峰谷特点,在系统容量无法处理大量并发时,对请求通过业务逻辑实现错峰分流,是解决性能问题一种常规手段。

  上文也提到,餐品窗口有不同类型,面条、盖浇饭等。这个其实是根据业务特点实现的定向分流,提高资源处理效率。如果都混在一起,性能应该不好。

   再一个,我们打饭其实包含了多个操作步骤:排队、取餐具、点餐、盛饭盛汤、落座、进食、返还餐具。对应到性能测试分析,可以借鉴的就是,业务处理要进行 细分,系统重点处理关键节点,业务请求本身能完成的事务由客户端完成,在请求时携带结果参数(餐具)。业务处理完成后,要及时完成垃圾回收释放资源。

  另外一个比较重要的地方就是应急处理,系统发生异常时要能保证提供最基本的服务。饭点时员工吃不上饭应该是这个系统不能接受的问题。其实可以考虑开个零售点备些面包、方便面啥的,这样至少停电、停气时还能满足最基本的充饥需求。

  基本就这么多,其实还有很多后台的工作我们看不到,其实应该对性能影响也是很大的,比如食材的准备、烹饪过程、配套设施的保障等,这边就不发散了。

  总结一下,从食堂系统来看,我们做性能分析其实大致要关注以下几点:

  1)业务请求的数量、并发请求数

  2)业务处理效率

  3)系统资源情况,处理能力

  4)业务处理的关键节点

  5)分流策略

  6)异常处理和应急机制

版权声明:本文出自 danmy 的51Testing软件测试博客:http://www.51testing.com/?81672

posted on 2013-01-21 10:25 顺其自然EVO 阅读(262) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜