從食堂就餐看性能測試分析

中午在機關食堂吃飯排了個長隊，等了好半天。然後就想這不就是在跑性能嗎？？

　　首先最直覺的性能表現就是打飯視窗的長隊，可以說這是系統性能處理能力最直覺的表現了。名額對應responsetime

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

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

　　我們再看看影響性能名額的相關因素

　　1）打飯視窗數--對應業務處理程序數，有時某個視窗存在多個打飯師傅，這時可以看作是多線程。處理程序（線程）的多少，是決定業務處理性能的最主要因素。

　　2）師傅的業務熟練程度--處理器的性能，計算能力

　　3）所點餐品多少和分布情況--對應資料的處理能力。所點餐品離視窗近，分布集中，自然處理起來快些，好比資料存儲在記憶體庫，不進行跨表、跨庫的關聯處理之類，性能自然較好。

　　4）刷卡付賬環節--一般組合的餐品價格師傅都能快速算出來，但是比較多的菜品，計算起來要多花點時間。好比對于一些常見的請求，從緩存裡讀取自然會快些。

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

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

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

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

　　1）二樓食堂人滿為患，一樓食堂比較寬松。這個給我們的啟示就是，在系統還具備處理能力的前提下，性能并不是影響使用者選擇的最主要參考（關鍵需求即業務本身的吸引力更重要）。但系統超過處理能力或者系統異常，無法提供服務後果還是很嚴重的。餓肚子咋幹活。。

　　2）業務上存在分時處理，所有的業務請求被強制分時間段通路。這個是根據業務特點決定的，業務具有明顯的峰谷特點，在系統容量無法處理大量并發時，對請求通過業務邏輯實作錯峰分流，是解決性能問題一種正常手段。

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

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

　　另外一個比較重要的地方就是應急處理，系統發生異常時要能保證提供最基本的服務。飯點時員工吃不上飯應該是這個系統不能接受的問題。其實可以考慮開個零售點備些面包、友善面啥的，這樣至少停電、停氣時還能滿足最基本的充饑需求。

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

　　1）業務請求的數量、并發請求數

　　2）業務處理效率

　　3）系統資源情況，處理能力

　　4）業務處理的關鍵節點

　　5）分流政策

　　6）異常處理和應急機制

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/