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

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

影响就餐的性能指标

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

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

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

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

影响因素

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

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

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

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

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

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

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

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

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

处理能力

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

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

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

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

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

应急处理

再一个比较重要的地方就是应急处理，系统发生异常时要能保证提供最基本的服务，比如去除非关键业务集中保证关键业务等。饭点时员工吃不上饭应该是这个系统不能接受的问题。其实可以考虑开个零售点备些面包、方便面啥的，这样至少特殊情况不能供餐时时还能满足最基本的充饥需求。

总结

基本就这么多，其实还有很多后台的处理从用户层面看不到，其实对性能影响也是很大的，比如食材的准备、烹饪过程、配套设施的保障等，对应到系统的后台调优，这边就不发散了。

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

• 业务请求的数量、并发请求数

• 业务处理效率

• 系统资源情况，处理能力

• 业务处理的关键节点

• 分流策略

• 异常处理和应急机制

其实IT行业的很多业务处理和解决办法，从其他行业都能找到共通的地方，多观察多思考必定能收获良多