首页手记从食堂就餐看性能测试分析

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

标签：

测试

此是一篇旧文，当时到公司食堂就餐，结果排了一个长队，过程中想到这不就是在对食堂系统进行性能测试吗？回来草就此篇。今日偶然翻得，与诸君共飨。

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

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

打饭窗口数 -- 对应业务处理进程数，有时某个窗口存在多个打饭师傅，这时可以看作是多线程。处理进程（线程）的多少，是决定业务处理性能的最主要因素。
师傅的业务熟练程度-- 处理器的性能，计算能力
所点餐品多少和分布情况-- 对应数据的处理能力。所点餐品离窗口近，分布集中，自然处理起来快些，好比数据存储在内存库，不进行跨表、跨库的关联处理之类，性能自然较好。
刷卡付账环节-- 一般组合的餐品价格师傅都能快速算出来，但是比较多的菜品，计算起来要多花点时间。好比对于一些常见的请求，从缓存里读取自然会快些。

异常情况1：卡内金额不够、点菜结束又再点了一份。对应到这些异常处理或是重试会也影响处理性能。
异常情况2：看菜单上有的菜，点菜时却发现没有，需要重新确认。这个相当于业务请求先查询出携带的参数，响应却判参数不存在了。数据实时关联没做好，属于系统Bug

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

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

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

二楼食堂人满为患，一楼食堂比较宽松。这个给我们的启示就是，在系统还具备处理能力的前提下，性能并不是影响用户选择的最主要因素（关键需求即业务本身的吸引力更重要）。但系统超过处理能力或者系统异常，无法提供服务后果还是很严重的。饿肚子咋干活...
业务上存在分时处理，所有的业务请求被强制分时间段访问。这个是根据业务特点决定的，业务具有明显的峰谷特点，在系统容量无法处理大量并发时，对请求通过业务逻辑实现错峰分流，是解决性能问题一种常规手段。

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

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