Web服務端性能提升實踐

隨著互聯網的不斷發展，日常生活中越來越多的需求通過網路來實現，從衣食住行到金融教育，從口袋到身份，人們無時無刻不依賴著網路，而且越來越多的人通過網路來完成自己的需求。

作為直接面對來自客戶請求的Web服務端，無疑要同時承受更多的請求，並為用戶提供更好的體驗。這個時候Web端的性能常常會成為業務發展的瓶頸，提升性能刻不容緩。本文作者在開發過程中總結了一些提升Web服務端性能的經驗，與大家分享。

問題分析

對於Web服務端性能，首先我們分析一下相關指標。從用戶角度講，用戶調用Web服務時，請求返回時間越短，用戶體驗越好。從服務端角度講，同一時間能承載用戶請求量越大，服務端性能就越強。綜合兩方面，我們總結性能優化的兩個方向：

1. 增加服務端所能支撐並發請求的最大數量；

2. 提高每個請求處理速度。

明確了優化方向，首先介紹一種服務端通常的架構模式，即來自瀏覽器或者App的Web一個請求，在服務端經過哪幾層結構被處理並返回的。

架構模式：IP負載均衡->緩存伺服器->反向代理->應用伺服器->資料庫

如圖1所示，為了說明方便，我們來舉個實際的例子: LVS(Keepalived)->Squid->nginx->Go->MySQL

圖1：服務端架構

我們對請求在每層做分發處理，這樣可以使下一級結構有多個分支同時工作，來提高總體的最大並發數。

結合架構，我們來分析通常有哪些問題在拖了性能的後腿，以及找出對應的解決方法。

正常情況下，IP負載均衡，緩存伺服器和nginx代理這幾層主要是集群穩定性問題。容易出現性能瓶頸的地方往往是應用伺服器層和資料庫層，我們下面來列舉幾個例子：

1. 阻塞的影響

（1）問題：

大部分Web請求都是阻塞性質的，當一個請求被處理時，進程就會被掛起（佔用CPU）直至請求完成。在大多數情況下，Web請求完成的足夠快，所以這個問題並不被關注。然而，對於那些響應時間來完成的請求（像返回數據量大的請求或外部API），這意味著應用程序被鎖定直至處理結束，這期間，其他的請求不會被處理，很明顯，這些無效的等待時間浪費掉了，並且佔用系統資源，嚴重的影響了我們可以負擔的並發請求的數量。

（2）解決辦法：

Web服務端在等待上一個請求處理的過程中，我們可以讓I/O循環打開以便處理其他應用請求，直到處理完成時啟動一個請求並給予反饋，而不再是等待請求完成的過程中掛起進程。這樣，我們可以節省一些沒有必要的等待時間，用這些時間去處理更多的請求，這樣我們就可以大大增加請求的吞吐量，也就是在宏觀上提高了我們可處理的並發請求數。

（3）例子

這裡我們用Python的一款Web框架Tornado來具體說明改變阻塞方式提高並發性能。

場景：我們構建一個向遠端（某個十分穩定的網站）發送HTTP請求的簡單Web應用。這期間，網路傳輸穩定，我們不考慮網路來帶的影響。

在這個例子中，我們使用Siege（一款壓力測試軟體）對服務端在10秒內執行大約10個並發請求。

如圖2所示，我們可以很容易看出，這裡的問題是無論每個請求自身返回多麼快，伺服器對遠端的訪問請求往返都會產生足夠大的滯後，因為進程直到請求完成並且數據被處理前都一直處於強制掛起狀態。當一兩個請求時這還不是一個問題，但達到100個（甚至10個）用戶時，這意味著整體變慢。如圖，不到10秒時間10個相似用戶的平均響應時間達到了1.99秒，共計29次。這個例子只展示了非常簡單的邏輯。如果你要添加其他業務邏輯或資料庫的調用的話，結果會更糟糕。增加更多的用戶請求時，同時可被處理的請求就會增長緩慢，甚至有些請求會發生超時或失敗。

圖2：阻塞式響應

下面我們用Tornado執行非阻塞的HTTP請求。

如圖3所示，我們從每秒3.20個事務提升到了12.59，在相同的時間內總共提供了118次請求。這真是一個非常大的改善！正如你所想像的，隨著用戶請求增多和測試時間增長時，它將能夠提供更多連接，並且不會遇到上面版本遭受的變慢的問題。從而穩定的提高了可負載的並發請求數。

圖3：非阻塞式響應

2. 計算效率對響應時間和並發數的影響

先來介紹一下基礎知識：一個應用程序是運行在機器上的一個進程；進程是一個運行在自己內存地址空間里的獨立執行體。一個進程由一個或多個操作系統線程組成，這些線程其實是共享同一個內存地址空間的一起工作的執行體。

（1）問題

傳統計算方式單線程運行，效率低，計算能力弱。

（2）解決辦法

一種解決辦法就是完全避免使用線程。例如，可以使用多個進程將重擔交給操作系統來處理。但是，有個劣勢就是，我們必須處理所有進程間通信，通常這比共享內存的並發模型有更多的開銷。

另一種辦法是用多線程工作，不過，公認的，使用多線程的應用難以做到準確，同步不同的線程，對數據加鎖，這樣同時就只有一個線程可以變更數據。不過過去的軟體開發經驗告訴我們這會帶來更高的複雜度，更容易使代碼出錯以及更低的性能。

其中最主要的問題是內存中的數據共享，它們會被多線程以無法預知的方式進行操作，導致一些無法重現或者隨機的結果（稱作「競態」）。所以這個經典的方法明顯不再適合現代多核/多處理器編程：thread-per-connection 模型不夠有效。在諸多比較合適的範式中，有個被稱作 Communicating Sequential Processes（順序通信處理）（CSP, C. Hoare 發明的）還有一個叫做 message-passing-model（消息傳遞）（已經運用在了其他語言中，比如 Erlang）。

我們這裡使用辦法是利用並行的架構來處理任務，一個並發程序可以在一個處理器或者內核上使用多個線程來執行任務，但是只有同一個程序在某個時間點同時運行在多核或者多處理器上才是真正的並行。

並行是一種通過使用多處理器以提高速度的能力。所以並發程序可以是並行的，也可以不是。

並行模式可以同時使用多線程、多核、多處理器，甚至多計算機，這無疑可以調動更多資源，從而壓縮響應時間，提升運算效率，極大地增強了服務端的性能。

（3）例子

這裡用Go語言中的Goroutine來具體說明。

在Go語言中，應用程序並發處理的部分被稱作 goroutines（協程），它可以進行更有效的並發運算。在協程和操作系統線程之間並無一對一的關係：協程是根據一個或多個線程的可用性，映射（多路復用，執行於）在他們之上的；協程調度器在 Go 運行時很好的完成了這個工作。協程是輕量的，比線程更輕。它們痕迹非常不明顯（使用少量的內存和資源）：使用 4K 的棧內存就可以在堆中創建它們。因為創建非常廉價，必要的時候可以輕鬆創建並運行大量的協程（在同一個地址空間中 100,000 個連續的協程）。並且它們對棧進行了分割，從而動態的增加（或縮減）內存的使用；棧的管理是自動的，但不是由垃圾回收器管理的，而是在協程退出後自動釋放。協程可以運行在多個操作系統線程之間，也可以運行在線程之內，讓你可以很小的內存佔用就可以處理大量的任務。由於操作系統線程上的協程時間片，你可以使用少量的操作系統線程就能擁有任意多個提供服務的協程，而且 Go 運行時可以聰明地意識到哪些協程被阻塞了，暫時擱置它們並處理其他協程。甚至，程序可以在不同的處理器和計算機上同時執行不同的代碼段。

我們通常想將一個長計算過程切分成幾塊，然後讓每個goroutine各自負責一塊工作，這樣對於單一請求的響應時間有成倍的提升。

舉個例子，有一個任務分3個階段，a階段去資料庫a中取數據，b階段去資料庫b中取數據，c階段合并數據返回。我們啟動goroutine以後a、b階段可以一起進行，極大地縮短了響應時間。

說白了就是部分計算過程由串列轉換為並行，一個任務不需要等待其他無關的任務執行完在執行，實際計算中程序的並行執行會更有用處。

關於這部分佐證的數據就不在這邊過多敘述了，感興趣的同學可以自己看一下這方面的資料。比如Web服務端由Ruby切換為Go性能提升15倍的老故事（Ruby使用的是綠色線程，即只有一個CPU得到利用）。雖然這個故事可能有點誇大，但是並行帶來的性能提升是毫無疑問的。（Ruby切換為Go：http://www.vaikan.com/how-we-went-from-30-servers-to-2-go/）。

3. 磁碟I/O對性能的影響

(1) 問題

磁碟讀取數據靠的是機械運動，每次讀取數據花費的時間可以分為尋道時間、旋轉延遲、傳輸時間三個部分，尋道時間指的是磁臂移動到指定磁軌所需要的時間，主流磁碟一般在5ms以下；旋轉延遲就是我們經常聽說的磁碟轉速，比如一個磁碟7200轉，表示每分鐘能轉7200次，也就是說1秒鐘能轉120次，旋轉延遲就是1/120/2 = 4.17ms；傳輸時間指的是從磁碟讀出或將數據寫入磁碟的時間，一般在零點幾毫秒，相對於前兩個時間可以忽略不計。那麼訪問一次磁碟的時間，即一次磁碟I/O的時間約等於9ms（5ms+4.17ms）左右，聽起來還挺不錯的，但要知道一台500 -MIPS的機器每秒可以執行5億條指令，因為指令依靠的是電的性質，換句話說執行一次I/O的時間可以執行40萬條指令，資料庫動輒十萬百萬乃至千萬級數據，每次9毫秒的時間，顯然是個災難。

(2) 解決辦法

磁碟I/O對伺服器性能的影響沒有根本的解決辦法，除非你把磁碟扔掉，換成別的東西。我們能在網上搜到各種存儲介質的響應速度與價格，如果你有錢，你就可以任性的更換存儲介質。

在不更換存儲介質的條件下，我們可以減少應用程序對磁碟的訪問次數，比如設置緩存，還可以把部分磁碟I/O放到請求周期外，比如用隊列和棧來處理數據的I/O等。

4. 優化資料庫查詢

隨著業務開發模式的變化，敏捷式開發被越來越多的團隊採用，周期越來越短，很多資料庫查詢語句都是按照業務邏輯來寫，時間久了常常就忽略了SQL查詢的格式問題，造成資料庫壓力的增加，使資料庫查詢的響應變慢。這裡簡單介紹MySQL資料庫中，幾條被我們忽略的常見問題和優化方式：

最左前綴匹配原則，非常重要的原則，MySQL會一直向右匹配直到遇到範圍查詢(>、 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。

盡量選擇區分度高的列作為索引，區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別欄位可能在大數據面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的欄位我們都要求是0.1以上，即平均1條掃描10條記錄。

盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

索引列不能參與計算，保持列「乾淨」，比如就不能使用到索引，原因很簡單，b+樹中存的都是數據表中的欄位值，但進行檢索時，需要把所有元素都應用函數才能比較，顯然成本太大。所以語句應該寫成;應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用。

索引而進行全表掃描，如：

可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：

應盡量避免在 where 子句中使用 or 來鏈接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：?

?

可以這樣查詢：

下面的查詢也將導致全表掃描(不能前置百分號)：

?

?若要提高效率，可以考慮全文檢索。

in 和 not in 也要慎用，否則會導致全表掃描，如：

?

? 對於連續的數值，能用 between 就不要用 in 了：?

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！