中午在單位食堂吃飯排了個長隊，等了好半天。然后就想這不就是在跑性能嗎？？
如果把食堂看作一個在線系統，員工吃飯看作是一次業務處理。回過頭來看系統性能測試分析中需要關注的點，其實頗有意思
首先最直觀的性能表現就是打飯窗口的長隊，可以說這是系統性能處理能力最直觀的表現了。指標對應ResponseTime
隊伍前進的快慢，對應每秒處理事務數TPS
同時進餐人數，對應并發請求數
我們再看看影響性能指標的相關因素
1）打飯窗口數--對應業務處理進程數，有時某個窗口存在多個打飯師傅，這時可以看作是多線程。處理進程（線程）的多少，是決定業務處理性能的最主要因素。
2）師傅的業務熟練程度--處理器的性能，計算能力
3）所點餐品多少和分布情況--對應數據的處理能力。所點餐品離窗口近，分布集中，自然處理起來快些，好比數據存儲在內存庫，不進行跨表、跨庫的關聯處理之類，性能自然較好。
4）刷卡付賬環節--一般組合的餐品價格師傅都能快速算出來，但是比較多的菜品，計算起來要多花點時間。好比對于一些常見的請求，從緩存里讀取自然會快些。
異常情況1：卡內金額不夠、點菜結束又再點了一份。對應到這些異常處理或是重試會也影響處理性能。
異常情況2：看菜單上有的菜，點菜時卻發現沒有，需要重新確認。這個相當于業務請求先查詢出攜帶的參數，響應卻判參數不存在了。數據實時關聯沒做好，屬于系統Bug（此Bug還存在啊）
5）選擇的餐品類型---打飯的隊伍比等面條、餛飩的隊伍處理起來一般相對快些。不同業務，處理的方式不同，性能表現也不同。
另外，餐廳的面積是有限的，窗口數也是有限的，打飯師傅的數量也是有限的。所以系統處理能力或曰系統容量是有限的。貌似目前食堂還沒達到處理極限（雖然用戶滿意度不高），暫時還不用擴容，呵呵
其實我們注意到，針對處理能力的問題，有兩個現象：
1）二樓食堂人滿為患，一樓食堂比較寬松。這個給我們的啟示就是，在系統還具備處理能力的前提下，性能并不是影響用戶選擇的最主要參考（關鍵需求即業務本身的吸引力更重要）。但系統超過處理能力或者系統異常，無法提供服務后果還是很嚴重的。餓肚子咋干活。。
2）業務上存在分時處理，所有的業務請求被強制分時間段訪問。這個是根據業務特點決定的，業務具有明顯的峰谷特點，在系統容量無法處理大量并發時，對請求通過業務邏輯實現錯峰分流，是解決性能問題一種常規手段。
上文也提到，餐品窗口有不同類型，面條、蓋澆飯等。這個其實是根據業務特點實現的定向分流，提高資源處理效率。如果都混在一起，性能應該不好。
再一個，我們打飯其實包含了多個操作步驟：排隊、取餐具、點餐、盛飯盛湯、落座、進食、返還餐具。對應到性能測試分析，可以借鑒的就是，業務處理要進行 細分，系統重點處理關鍵節點，業務請求本身能完成的事務由客戶端完成，在請求時攜帶結果參數（餐具）。業務處理完成后，要及時完成垃圾回收釋放資源。
另外一個比較重要的地方就是應急處理，系統發生異常時要能保證提供最基本的服務。飯點時員工吃不上飯應該是這個系統不能接受的問題。其實可以考慮開個零售點備些面包、方便面啥的，這樣至少停電、停氣時還能滿足最基本的充饑需求。
基本就這么多，其實還有很多后臺的工作我們看不到，其實應該對性能影響也是很大的，比如食材的準備、烹飪過程、配套設施的保障等，這邊就不發散了。
總結一下，從食堂系統來看，我們做性能分析其實大致要關注以下幾點：
1）業務請求的數量、并發請求數
2）業務處理效率
3）系統資源情況，處理能力
4）業務處理的關鍵節點
5）分流策略
6）異常處理和應急機制
版權聲明：本文出自 danmy 的51Testing軟件測試博客：http://www.51testing.com/?81672