關於若干性能指標的闡述

目錄

應用程序性能指標
響應時長
併發數
吞吐量
如何提高應用的響應能力
儘量地壓縮響應時長
設置合理的併發數量
在開始以前必須說明，本文力圖簡單的描述而非學院派解釋。

應用程序性能指標
通常地說，單一指標沒法勾畫出總體水平，咱們須要綜合使用響應時長、併發數、吞吐量等各類指標描述應用的響應能力。網絡上對相關指標有詳細描述，這裏做出部分解釋、補充和示例。

響應時長
響應時長是指系統對請求做出響應的時間，用戶對該指標有直觀感覺。

舉例：乘坐火車須要檢票，需關照的乘客進站效率低，火車站會開放優先通道以應對。
提問：響應時長能夠被無限壓縮嗎？
多數請求須要獲取各類資源，當發生資源爭用時，響應時長沒法被壓縮。

例如用戶須要獲取 100萬條記錄，不討論內存是否夠用的狀況，如此多的記錄被讀取出來，加上網絡傳輸的時間是請求時長的絕對開銷。縱然業務再優化，請求時長也不會有更多壓縮空間。

DNS 解析、腳本加載，頁面渲染等不在本文討論之列，趕興趣請以關鍵字 "從輸入頁面地址到展現頁面信息都發生了些什麼" 搜索相關內容。

併發數
併發用戶數是指系統能夠同時承載的正常使用系統功能的用戶的數量。

舉例：火車站會在節假日加開更多的檢票通道。
提問：增長檢票通道就是提升併發數，能夠無限增長檢票通道嗎？
提高併發數可以減小排隊階段的請求數量，可是面臨資源瓶頸時，狀況變得不同。

咱們知道檢票進站後立刻須要安檢，安檢內容之一是使用 X 光機檢查乘客行李。爲了便於計算假定乘客不少且檢票與安檢時長一致，檢票窗口已經排隊，那麼當有 15 臺 X 光機時：

若是隻開放 10 個檢票通道，可是車站內部有 5 臺 X 光機處於空置狀態；
若是開放到 15 個檢票通道，那麼所有 X 光機都處於工做狀態，無人排隊安檢；
若是開放到 20 個檢票通道，那麼額外的 5 名乘客經過檢票通道後，須要再次排隊安檢。
以上入站系統中併發數分別爲 十、1五、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 我的同時瀏覽頁面能產生多少併發？這很複雜，用戶不是每時每刻在刷新頁面，瀏覽器支持的併發數量、相關頁面發起的請求數、網絡狀況等隨時在變化，造成的峯值也沒法長時間維持；
單個請求的完成時長，與最大併發數量無直接關係；
爲了使響應能力最大化，部分組件的限流手段會設置併發上限；
吞吐量 = 併發數量/響應時長

綜上咱們須要綜合使用響應時長、併發數、吞吐量等各類指標描述應用的響應能力，而吞吐量則更加直觀準確。

如何提高應用的響應能力
咱們已經知道響應時長、併發數與吞吐量的關係：響應時長越短，併發數越高，吞吐量就越好，應用響應能力就越優秀。反過來來講，若是請求至關耗時，那麼追求優秀的響應能力或者併發能力，等同於緣木求魚。

儘量地壓縮響應時長
在業務許可的狀況下，對於形如須要從數據庫獲取數據的請求，如下措施是可行手段：

縮短前置、後置步驟；
壓縮外部依賴響應時長；
確保命中數據庫索引；
嘗試減小獲取的指標數量；
嘗試減小獲取的記錄數量；
嘗試分頁屢次獲取；
嘗試從緩存獲取並穩當處理一致性問題；
當沒法避免巨量的資源獲取時，直接拒絕相關請求也是務實高效的手段。

設置合理的併發數量
由前文可知，併發數既不是一個有效的性能指標，該指標也不是越大越好，設置合適的併發數量須要經過調優實現，但調優不是一件容易事。

總結使用場景；在各類場景下針對不一樣配置，設置併發參數並展開測試，描繪響應能力曲線；配置變動和應用迭代時重複進行；綜上，應用及其背後的全部依賴共同做用，決定了應用的響應能力。