QPS 和並發：如何衡量伺服器端性能

在 LeanCloud 的控制台和文檔中大家會接觸到「並發連接數（Concurrent Connections）」這個衡量伺服器負荷或處理能力的概念，但很多人並不了解什麼是並發 —— 甚至在我們團隊內部，很多沒有伺服器端開發經驗的工程師對這個詞的理解也不是很準確。我們還在繼續優化文案來減少用戶的困惑，但與此同時不如聽我仔細介紹一下並發這個概念。

和並發相關不得不提的一個概念就是 QPS（Query Per Second），QPS 其實是衡量吞吐量（Throughput）的一個常用指標，就是說伺服器在一秒的時間內處理了多少個請求 —— 我們通常是指 HTTP 請求，顯然數字越大代表伺服器的負荷越高、處理能力越強。作為參考，一個有著簡單業務邏輯（包括資料庫訪問）的程序在單核心運行時可以提供 50 - 100 左右的 QPS，即每秒可以處理 50 - 100 個請求，LeanCloud 目前也是按照請求數量進行收費的。

但 QPS 只能粗略地衡量請求的數量，完全不關心伺服器處理每個請求的開銷。例如一個命中緩存的請求和一個需要進行多次資料庫查詢的請求的開銷可能會有一個數量級的差距，所以 QPS 並不能十分精確地衡量伺服器的負載或處理能力，因此我們引入了一個非常抽象的概念 —— 並發。

大部分請求的響應時間在 15 - 30 毫秒左右，這裡的響應時間是指伺服器處理這個請求所花費的時間，從客戶端測量到的時間可能會稍長一些。想像如果伺服器上只有一個 CPU 核心在逐個地在處理請求，如果每個請求花費 15 毫秒的話，那麼每秒可以處理 66 個請求，也就是我們前面提到的 66 QPS；而如果都是複雜的請求，每個需要 30 毫秒的話，那麼伺服器就只有 33 QPS 了。可以看到在處理能力不變的情況下（只有一個核心），響應時間越高，QPS 就越低。又如果在響應時間不變的情況下，如果我們增加一個 CPU，QPS 就會翻倍，這三者之間的關係可以簡單地描述成：吞吐量（QPS）= 處理能力（CPU）/ 響應時間。

其實 CPU 的數量就是並發最基本的概念，即有多少個 CPU 在工作。當然在實際的伺服器端環境中，我們在 CPU 的基礎上建立起了進程、線程、協程這樣複雜的抽象、通過非同步的 IO 提高 CPU 的利用率 —— 當需要從硬碟或網路讀取數據時，CPU 會去做其他工作，所以並發和 CPU 的比值會比 1 高一些，IO 越多，這個比值會越高。

這時我們可以觀測到的並發數就是伺服器在同時處理多少個請求，也即「並發連接數」。對於 Web 後端的場景來說（而不考慮推送等長鏈接的場景），我們希望儘快地給客戶端響應，所以請求在伺服器端花費的幾十毫秒中每一毫秒都是必不可少的：可能是在進行計算、也可能是在向磁碟或網路讀寫數據，都在佔用著伺服器的資源，因此並發依然是衡量伺服器負荷和處理能力的關鍵指標。

除了並發本身，我們還經常提到「最大並發」的概念，最大並發就是在單位時間（通常是一天）里並發最高的那一刻有多少個 CPU 在為你工作。大部分應用的請求量並不是均勻地分布在一天中的，因為用戶們往往會集中在傍晚的幾個小時中使用手機，這些時段中的請求量要遠遠高於凌晨。所以人人都希望在傍晚得到更多的計算能力，但遺憾的是這些計算能力需要原子世界中的 CPU 去支持，你不可能在傍晚購買一批伺服器然後在凌晨賣掉（當然，這其實是雲計算要解決的問題），所以為了支撐傍晚的高並發，我們必須去準備那麼多的伺服器、必須在凌晨讓很多伺服器閑置，因此其實我們只關心一天中最高的並發數 —— 這代表了我們需要採購多少硬體資源。

當然，LeanCloud 的存在就是為了幫助開發者減輕維護後端的負擔，應用開發者往往更關注的是「我有 100 萬用戶對應多少並發」。但這個問題往往得不到一個答案，因為有太多的因素在影響著最後的結果，例如你的 100 萬用戶中可能並不是每個人每天都會打開你的應用（每日活躍用戶比例）；而且用戶對於不同類型的應用使用的頻率也並不相同（平均打開次數）；不同類型的應用在工作期間發起的請求數量也不相同（平均請求數量）；對於不同類型的請求，需要佔用伺服器的計算能力同樣不同（平均響應時間）；最後還要考慮到你的大部分用戶會集中在傍晚的幾個小時使用你的應用，對於遊戲抽獎、電商秒殺之類的場景，用戶會更加集中在幾分鐘內使用你的應用。前些天我根據這些指標編寫了一個簡單的計算器（ https://budget.leanapp.cn ），將最大並發數的計算抽象為了前面提到的幾個指標，如果你能給每個指標一個相對準確的估算，那麼就可以計算出一個可供參考的並發數。