QPS 和併發：如何衡量服務器端性能

        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
版權聲明：本文爲博主原創文章，轉載請附上博文連接！