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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2） 业务处理效率

3） 系统资源情况，处理能力

4） 业务处理的关键节点

5） 分流策略

6） 异常处理和应急机制