程序性能指標
關於若干性能指標的闡述
在開始之前必須說明，本文力圖簡單的描述而非學院派解釋。
應用程序性能指標
一般地說，單一指標無法勾畫出整體水平，我們需要綜合使用響應時長、並發數、吞吐量等各種指標描述應用的響應能力。網絡上對相關指標有詳細描述，這里作出部分解釋、補充和示例。
響應時長
響應時長是指系統對請求作出響應的時間，用戶對該指標有直觀感受。
- 舉例：乘坐火車需要檢票，需關照的乘客進站效率低，火車站會開放優先通道以應對。
- 提問：響應時長可以被無限壓縮嗎？
多數請求需要獲取各種資源，當發生資源爭用時，響應時長無法被壓縮。
例如用戶需要獲取 100萬條記錄，不討論內存是否夠用的情況，如此多的記錄被讀取出來，加上網絡傳輸的時間是請求時長的絕對開銷。縱然業務再優化，請求時長也不會有更多壓縮空間。
DNS 解析、腳本加載，頁面渲染等不在本文討論之列，趕興趣請以關鍵字 "從輸入頁面地址到展示頁面信息都發生了些什么" 搜索相關內容。
並發數
並發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量。
- 舉例：火車站會在節假日加開更多的檢票通道。
- 提問：增加檢票通道就是提高並發數，可以無限增加檢票通道嗎？
提升並發數能夠減少排隊階段的請求數量，但是面臨資源瓶頸時，情況變得不一樣。
我們知道檢票進站后馬上需要安檢，安檢內容之一是使用 X 光機檢查乘客行李。為了便於計算假定乘客很多且檢票與安檢時長一致，檢票窗口已經排隊，那么當有 15 台 X 光機時：
- 如果只開放 10 個檢票通道，但是車站內部有 5 台 X 光機處於空置狀態；
- 如果開放到 15 個檢票通道，那么全部 X 光機都處於工作狀態，無人排隊安檢；
- 如果開放到 20 個檢票通道，那么額外的 5 名乘客通過檢票通道后，需要再次排隊安檢。
以上入站系統中並發數分別為 10、15、20，並且最后一種情況產生額外的內部隊伍。隨着時間流逝，排隊安檢的人將越來越多並最終擠爆安檢大廳。在各種安檢場所可以看到，維持秩序的工作人員每次只放一批乘客，就是避免出現這種情況。
在業務系統中，如果資源爭用引發排隊，會使內存持續上漲，最終導致應用無法響應——更多的並發數只會使應用死得更快。常用應對手段就是限流，直接拋棄掉不能處理的請求。
吞吐量
吞吐量是指系統在單位時間內處理請求的數量，相關詞匯有QPS、TPS、RPM 等，語義和適用場景略有差異。
- QPS：queries per second，平均每秒請求數量；
- TPS：transactions per second，平均每秒事務數量；
- RPM：request per minute，平均每分鍾請求數量；
提問：A 系統最大支持100個並發，平均請求耗時 0.8 秒，B 系統最大支持 70 個並發，平均請求耗時 0.5 秒，哪個系統的響應能力更優？
這就引入了吞吐量的概念，A 系統每秒能夠完成 100/0.8 = 125 個請求，B 系統每秒能夠完成 70/0.5 = 140 個請求，事實上 B 系統更優。
服務端意義上能夠支持的並發數，並不能作為響應能力的主要指標，有若干原因：
- 達到最大並發數的情況並不是總是發生，100 個人同時瀏覽頁面能產生多少並發？這很復雜，用戶不是每時每刻在刷新頁面，瀏覽器支持的並發數量、相關頁面發起的請求數、網絡情況等隨時在變化，形成的峰值也無法長時間維持；
- 單個請求的完成時長，與最大並發數量無直接關系；
- 為了使響應能力最大化，部分組件的限流手段會設置並發上限；
吞吐量 = 並發數量/響應時長
綜上我們需要綜合使用響應時長、並發數、吞吐量等各種指標描述應用的響應能力，而吞吐量則更加直觀准確。
如何提升應用的響應能力
我們已經知道響應時長、並發數與吞吐量的關系：響應時長越短，並發數越高，吞吐量就越好，應用響應能力就越優秀。反過來來說，如果請求相當耗時，那么追求優秀的響應能力或者並發能力，等同於緣木求魚。
盡可能地壓縮響應時長
在業務許可的情況下，對於形如需要從數據庫獲取數據的請求，以下措施是可行手段：
- 縮短前置、后置步驟；
- 壓縮外部依賴響應時長；
- 確保命中數據庫索引；
- 嘗試減少獲取的指標數量；
- 嘗試減少獲取的記錄數量；
- 嘗試分頁多次獲取；
- 嘗試從緩存獲取並妥當處理一致性問題；
當無法避免巨量的資源獲取時，直接拒絕相關請求也是務實高效的手段。
設置合理的並發數量
由前文可知，並發數既不是一個有效的性能指標，該指標也不是越大越好，設置合適的並發數量需要通過調優實現，但調優不是一件容易事。
- 總結使用場景；
- 在各種場景下針對不同配置，設置並發參數並展開測試，描繪響應能力曲線；
- 配置變更和應用迭代時重復進行；
綜上，應用及其背后的所有依賴共同作用，決定了應用的響應能力。