QPS 和並發：如何衡量服務器端性能
和並發相關不得不提的一個概念就是 QPS（Query Per Second），QPS 其實是衡量吞吐量（Throughput）的一個常用指標，就是說服務器在一秒的時間內處理了多少個請求 —— 我們通常是指 HTTP 請求，顯然數字越大代表服務器的負荷越高、處理能力越強。作為參考，一個有着簡單業務邏輯（包括數據庫訪問）的程序在單核心運行時可以提供 50 - 100 左右的 QPS，即每秒可以處理 50 - 100 個請求。
但 QPS 只能粗略地衡量請求的數量，完全不關心服務器處理每個請求的開銷。例如一個命中緩存的請求和一個需要進行多次數據庫查詢的請求的開銷可能會有一個數量級的差距，所以 QPS 並不能十分精確地衡量服務器的負載或處理能力，因此我們引入了一個非常抽象的概念 —— 並發。
大部分請求的響應時間在 15 - 30 毫秒左右，這里的響應時間是指服務器處理這個請求所花費的時間，從客戶端測量到的時間可能會稍長一些。想象如果服務器上只有一個 CPU 核心在逐個地在處理請求，如果每個請求花費 15 毫秒的話，那么每秒可以處理 66 個請求，也就是我們前面提到的 66 QPS；而如果都是復雜的請求，每個需要 30 毫秒的話，那么服務器就只有 33 QPS 了。可以看到在處理能力不變的情況下（只有一個核心），響應時間越高，QPS 就越低。又如果在響應時間不變的情況下，如果我們增加一個 CPU，QPS 就會翻倍，這三者之間的關系可以簡單地描述成：吞吐量（QPS）= 並發數/平均響應時間［一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降］。
其實 CPU 的數量就是並發最基本的概念，即有多少個 CPU 在工作。當然在實際的服務器端環境中，我們在 CPU 的基礎上建立起了進程、線程、協程這樣復雜的抽象、通過異步的 IO 提高 CPU 的利用率 —— 當需要從硬盤或網絡讀取數據時，CPU 會去做其他工作，所以並發和 CPU 的比值會比 1 高一些，IO 越多，這個比值會越高。
這時我們可以觀測到的並發數就是服務器在同時處理多少個請求，也即「並發連接數」。對於 Web 后端的場景來說（而不考慮**等長鏈接的場景），我們希望盡快地給客戶端響應，所以請求在服務器端花費的幾十毫秒中每一毫秒都是必不可少的：可能是在進行計算、也可能是在向磁盤或網絡讀寫數據，都在占用着服務器的資源，因此並發依然是衡量服務器負荷和處理能力的關鍵指標。
除了並發本身，我們還經常提到「最大並發」的概念，最大並發就是在單位時間（通常是一天）里並發最高的那一刻有多少個 CPU 在為你工作。大部分應用的請求量並不是均勻地分布在一天中的，因為用戶們往往會集中在傍晚的幾個小時中使用手機，這些時段中的請求量要遠遠高於凌晨。所以人人都希望在傍晚得到更多的計算能力，但遺憾的是這些計算能力需要原子世界中的 CPU 去支持，你不可能在傍晚購買一批服務器然后在凌晨下掉（當然，這其實是雲計算要解決的問題），所以為了支撐傍晚的高並發，我們必須去准備那么多的服務器、必須在凌晨讓很多服務器閑置，因此其實我們只關心一天中最高的並發數 —— 這代表了我們需要采購多少硬件資源。
---------------------
作者：樂楊俊
來源：CSDN
原文：https://blog.csdn.net/leyangjun/article/details/64131491
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！