提升網站的吞吐量

時間 2020-09-24

原文原文鏈接

吞吐量定義

百科程序員

吞吐量是指對網絡、設備、端口、虛電路或其餘設施，單位時間內成功地傳送數據的數量（以比特、字節、分組等測量）。

以上的定義比較寬泛，定義到網站或者接口的吞吐量是這樣的：吞吐量是指系統在單位時間內處理請求的數量。這裏有一個注意點就是單位時間內，對於網站的吞吐量這個單位時間通常定義爲1秒，也就是說網站在一秒以內能處理多少http（https/tcp）請求。與吞吐量對應的衡量網站性能的還有響應時間、併發數、QPS每秒查詢率。golang

響應時間是一個系統最重要的指標之一，它的數值大小直接反應了系統的快慢。響應時間是指執行一個請求從開始到最後收到響應數據所花費的整體時間。
併發數是指系統同時能處理的請求數量，這個也是反應了系統的負載能力。面試

每秒查詢率(QPS)是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，做爲域名系統服務器的機器的性能常常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數，也便是最大吞吐能力。算法

咱們以高速收費站爲例子也許更直觀一些，吞吐量就是一天以內經過的車輛數，響應時間就是車速，併發數就是高速上同時奔跑的汽車數。因而可知其實以上幾個指標是有內在聯繫的。好比：響應時間縮短，在必定程度上能夠提升吞吐量。數據庫

其實以上幾個指標主要反映了兩個概念：編程

系統在單位時間以內能作多少事情
系統作一件事情須要的時間

提升吞吐量

如下場景都是在假設程序不發生異常的狀況下

服務器（進程）級別

服務器級別增長網站吞吐量也是諸多措施中最容易而且是效果最好的，若是一個網站能經過增長少許的服務器來提升吞吐量，菜菜以爲是應該優先採用的。畢竟一臺服務器的費用相比較一個程序員費用來講要低的多。可是有一個前提，就是你的服務器是系統的瓶頸，網站系統以後的其餘系統並不是瓶頸。若是你的系統的瓶頸在DB或者其餘服務，盲目的增長服務器並不能解決你的問題。設計模式

經過增長服務器來解決你的網站瓶頸，意味着你的網站須要作負載均衡，若是沒有運維相關人員，你可能還得須要研究負載均衡的方案，好比LVS，Nginx，F5等。我曾經面試過不少入道不久的同窗，就提升吞吐量問題，若是沒有回答上用負載均衡方案的基本都pass了，不要說別的，這個方案就是一個基礎，就比如學習一個語言，你連最基本的語法都不會，我憑什麼讓你經過。有噴的同窗能夠留言哦緩存

其實如今不少靜態文件採用CDN，本質上也能夠認爲是增長服務器的策略

線程級別

當一個請求到達服務器而且正確的被服務器接收以後，最終執行這個請求的載體是一個線程。當一個線程被cpu載入執行其指令的時候，在同步的狀態下，當前線程會阻塞在那裏等待cpu結果，若是cpu執行的是比較慢的IO操做，線程會一直被阻塞閒置很長時間，這裏的很長是對比cpu的速度而言，若是你想有一個直觀的速度對比，能夠去查看菜菜之前的文章：服務器

高併發下爲何更喜歡進程內緩存網絡

當一個新的請求到來的時候，若是沒有新的線程去領取這個任務並執行，要麼會發生異常，要麼建立新的線程。線程是一種很稀缺的資源，不可能無限制的建立。這種狀況下咱們就要把線程這種資源充分利用起來，不要讓線程停下來。這也是程序推薦採用異步的緣由，試想，一個線程不停的在工做，遇到比較慢的IO不會去等待結果，而是接着處理下一個請求，當IO的結果返回來獲得通知的時候，線程再去取IO結果，豈不是能在相同時間內處理更多的請求。

程序異步化（非阻塞）會明顯提升系統的吞吐量，可是響應時間可能會稍微變大

還有一點，儘可能減小線程上線文在cpu的切換，由於線程上線文切換的成本也是比較大的，在線程切換的時候，cpu須要把當前線程的上下文信息記錄下來用如下次調用的時候使用，而後把新線程的上下文信息載入而後執行。這個過程相對於cpu的執行速度而言，要慢不少。

不要拿Golang反駁以上觀點，golang的協程雖然是用戶級別比線程更小的載體，可是最終和Cpu進行交互的仍是線程。

Cpu級別

在講cpu級別以前，若是有必定的網絡模型的基礎，也許會好一些。這裏大致闡述一下，現代操做系統都採用虛擬尋址的方式，它的尋址空間（虛擬存儲空間）爲4G（2的32次方）。操做系統將虛擬空間分爲兩類：內核空間和用戶空間。內核空間獨立於用戶空間，有訪問受保護的內存空間、IO設備的權限（全部的用戶空間共享）。用戶空間就是咱們的應用程序運行的空間，其實用戶空間並無操做各類IO設備的權限，像咱們平時讀取一個文件，本質上是委託內核空間去執行讀取指令的，內核空間讀取到數據以後再把數據複製到程序運行的空間，最後應用程序再把數據返回調用方。

經過上圖大致能夠看出，內核會爲每一個I/O設備維護一個buffer（同一個文件描述符讀和寫的buffer不一樣），應用程序發出一個IO操做的指令其實經過了內核空間和用戶空間兩個部分，而且發生了數據的複製操做。這個過程其實主要包含兩個步驟：

用戶進程發出操做指令並等待數據
內核把數據返回給用戶進程（buffer的複製操做）

根據這兩個操做的不一樣表現，因此IO模型有了同步阻塞，同步非阻塞，異步阻塞，異步非阻塞的概念，可是這裏並不是此文的重點，因此不在展開詳細介紹。

利用cpu提升系統吞吐量主要目標是提升單位時間內cpu運行的指令數，避免cpu作一些無用功：

cpu負責把buffer的數據copy到應用程序空間，應用程序再把數據返回給調用方，假如這個過程發生的是一次Socket操做，應用程序在獲得IO返回數據以後，還須要網卡把數據返回給client端，這個過程又須要把剛剛獲得的buffer數據再次經過內核發送至網卡，經過網絡傳送出去。因而可知cpu把buffer數據copy到應用程序空間這個過程徹底沒有必要，在內核空間徹底能夠把buffer數據直接傳輸至網卡，這也是零拷貝技術要解決的問題。具體的零拷貝技術在這裏再也不展開。

不要讓任何設備停下來，不要讓任何設備作無用功
經過增長cpu的個數來增長吞吐量

網絡傳輸級別

至於網絡傳輸級別，因爲協議大部分是Tcp/ip，因此在協議傳輸方面優化的手段比較少，可是應用程序級別協議能夠選擇壓縮率更好的，好比採用grpc會比單純的http協議要好不少，http2 要比http 1.1要好不少。另一方面網卡儘可能加大傳輸速率，好比千兆網卡要比百兆網卡速度更快。因爲網絡傳輸比較偏底層，因此人工干預的切入點會少不少。