食堂就餐與性能測試分析

來自專欄 軟體測試雜談

此是一篇舊文，當時到公司食堂就餐，結果排了一個長隊，過程中想到這不就是在對食堂系統進行性能測試嗎？回來草就此篇。今日偶然翻得，與諸君共饗。

影響就餐的性能指標

如果把食堂看作一個在線系統，員工吃飯看作是一次業務處理。回過頭來看系統性能測試分析中需要關注的點，其實頗有意思。

首先最直觀的性能表現就是打飯窗口的長隊，可以說這是系統性能處理能力最直觀的表現了。指標對應Response Time

隊伍前進的快慢，對應每秒處理事務數TPS

同時進餐人數，對應並發請求數

影響因素

我們再看看影響性能指標的相關因素

1. 打飯窗口數 -- 對應業務處理進程數，有時某個窗口存在多個打飯師傅，這時可以看作是多線程。 處理進程（線程）的多少，是決定業務處理性能的最主要因素。
2. 師傅的業務熟練程度 -- 處理器的性能，計算能力
3. 所點餐品多少和分布情況 -- 對應數據的處理能力。 所點餐品離窗口近，分布集中，自然處理起來快些，好比數據存儲在內存庫，不進行跨表、跨庫的關聯處理之類，性能自然較好。
4. 刷卡付賬環節 -- 一般組合的餐品價格師傅都能快速算出來，但是比較多的菜品，計算起來要多花點時間。 好比對於一些常見的請求，從緩存里讀取自然會快些。

異常情況1： 卡內金額不夠、點菜結束又再點了一份。 對應到這些異常處理或是重試會也影響處理性能。

異常情況2： 看菜單上有的菜，點菜時卻發現沒有，需要重新確認。 這個相當於業務請求先查詢出攜帶的參數，響應卻判參數不存在了。 數據實時關聯沒做好，屬於系統Bug

5. 選擇的餐品類型 --- 打飯的隊伍比等麵條、餛飩的隊伍處理起來一般相對快些。不同業務，處理的方式不同，性能表現也不同。

除此之外，餐廳的面積是有限的，窗口數也是有限的，打飯師傅的數量也是有限的。 所以系統處理能力或曰系統容量是有限的。貌似目前食堂還沒達到處理極限（雖然用戶滿意度不高），暫時還不用擴容。：）

處理能力

其實我們注意到，針對處理能力的問題，有兩個現象：

• 二樓食堂人滿為患，一樓食堂比較寬鬆。 這個給我們的啟示就是，在系統還具備處理能力的前提下，性能並不是影響用戶選擇的最主要因素（關鍵需求即業務本身的吸引力更重要）。但系統超過處理能力或者系統異常，無法提供服務後果還是很嚴重的。 餓肚子咋幹活...
• 業務上存在分時處理，所有的業務請求被強制分時間段訪問。這個是根據業務特點決定的，業務具有明顯的峰谷特點，在系統容量無法處理大量並發時，對請求通過業務邏輯實現錯峰分流，是解決性能問題一種常規手段。

上文也提到，餐品窗口有不同類型，麵條、蓋澆飯等。這個其實是根據業務特點實現的定向分流，提高資源處理效率。如果都混在一起，性能應該不好。

再一個，我們打飯其實包含了多個操作步驟：排隊、取餐具、點餐、盛飯盛湯、落座、進食、返還餐具。 對應到性能測試分析，可以借鑒的就是，業務處理要進行細分，系統重點處理關鍵節點，業務請求本身能完成的事務由客戶端完成，在請求時攜帶結果參數（餐具）。 業務處理完成後，要及時完成垃圾回收釋放資源。

應急處理

再一個比較重要的地方就是應急處理，系統發生異常時要能保證提供最基本的服務，比如去除非關鍵業務集中保證關鍵業務等。飯點時員工吃不上飯應該是這個系統不能接受的問題。其實可以考慮開個零售點備些麵包、速食麵啥的，這樣至少特殊情況不能供餐時時還能滿足最基本的充饑需求。

總結

基本就這麼多，其實還有很多後台的處理從用戶層面看不到，其實對性能影響也是很大的，比如食材的準備、烹飪過程、配套設施的保障等，對應到系統的後台調優，這邊就不發散了。

總結一下，從食堂系統來看，我們做性能分析其實大致要關注以下幾點：

• 業務請求的數量、並發請求數
• 業務處理效率
• 系統資源情況，處理能力
• 業務處理的關鍵節點
• 分流策略
• 異常處理和應急機制

其實IT行業的很多業務處理和解決辦法，從其他行業都能找到共通的地方，多觀察多思考必定能收穫良多

推薦閱讀：