性能測試入門解讀

背景介紹

項目越作越大，用戶量和請數量可能隨時發生井噴，若是等到系統崩潰時再補救，損失可就大了，因此得想個辦法提早預防。

想要預防，就得知道系統的哪一個環比較節薄弱，頂不住壓力，還要對系統的承受能力有個全面的評估，內心有底，好提早預防，這種評估分析預防優化等一系列手段全被性能測試涵蓋在內。

性能的指標

不一樣角色對性能的理解不盡相同，對於用戶來講，操做流不流暢就是性能，對於研發人員來講，接口慢不慢和頂不頂得住併發就是性能，對於運維人員來講，網絡帶寬大小和資源佔用高低就是性能。

那就必要統一性能指標了，首先，用戶與研發人員都關注速度，其實是接口的處理速度，再細一些是客戶端發起請求到收到服務端返回的時間，那就把這個指標定爲響應時間吧。

咱們作一款產品最須要的就是用戶，用戶越多越好，但隨着用戶量地增長，同時發起操做的用戶也愈來愈多，一時之間服務器可能要處理上萬的請求，在這同一時刻處理的請求數就叫作併發數，不知什麼時候起，處理太高併發的人成爲了你們眼中的瑰寶，而併發數也成爲了產品作大作強的標誌，因此併發數也要列入性能的指標。

併發數只能表明同時請求的數量不少，但並無賦予太多含義，與他人談論時也沒法讓人總體把握系統的概況，因此須要將併發數進行變種以應對不一樣業務不一樣場景的描述，好比一天有多少人訪問，一個小時能處理多少業務，每秒處理的事務數（TPS），每秒HTTP的請求數（HPS），每秒查詢數（QPS）等等，這個指標咱們爲其命名爲吞吐量。

除此以外，還要知足運維人員的要求，他們須要根據系統負載、內存佔用、CPU佔用、網絡磁盤I/O等各項指標進行分析，以便於爲擴容作準備，這種一系列的硬件指標咱們統稱爲性能計數器。

簡單說明一下系統負載，它是指CPU當前正在執行的與等待執行的進程數總和，該數量能夠體現出系統是否繁忙，咱們最但願看到的是沒有進程排隊等候，因此最理想的負載數量就是CPU的數量。

四種測試類型

咱們在開發時會對系統的性能有個初步的預期，而後經過模擬請求程序逐步加大請求壓力，直到你認爲服務器資源的消耗已經沒法接受了，此時再觀察系統性能是否達到了預期，這種方式就是性能測試。注意，名稱雖與上述重複但不是一個概念。

咱們繼續加大請求壓力，直到服務器的某個資源已經達到飽和了，或者性能計數器中的某個指標達到了安全臨界值，簡單地說，再請求下去，系統的處理能力不但不能提升，反而會降低了。這種測試方式叫作負載測試。

還能夠繼續加大壓力，不去管資源和性能指標如何，就瘋狂請求，不停地請求，直到服務器崩潰，不能再繼續工做了，這個時候就測出了系統最大承受能力，而這種測試方式被稱爲壓力測試。

沒辦法再繼續施壓了，由於服務器已經沒有響應，那就模擬一些比較真實的場景吧，由於真實場景下的請求壓力是不均勻的，咱們能夠在特定環境、硬件和時間下給系統必定壓力，看看業務是否能穩定運行，這種測試方式叫作穩定性測試。

優化手段

由於一個完整的WEB請求包含前端和後端兩個部分，優化手段也從這兩部分出發。

WEB前端優化

減小請求。如今大部分請求使用的是HTTP1，每一個圖片、腳本以及樣式等資源的獲取都要客戶端單獨跑線程創建鏈接，資源過多時消耗會很大，能夠將不一樣類型的資源各整合至一個文件，這樣少許的請求就能拿到須要的數據。

瀏覽器緩存。由於圖片、腳本、樣式等資源使用頻率很低，沒有必要每次請求都從新下載，能夠經過設置HTTP的頭部信息將資源緩存起來，這樣能夠有效下降加載速度，被緩存的資源須要更新時，能夠經過修改資源文件名稱的方式讓瀏覽器從新下載。

壓縮。圖片、腳本、樣式等靜態資源通常都比較大，服務端能夠將資源文件進行壓縮，壓縮後的文件較小，下載速度也會變快，可是先後解壓縮文件會形成必定的壓力，因此壓縮手段要視業務狀況而定。

CSS與JS順序。由於瀏覽器會加載完全部的CSS後纔去渲染頁面，因此應該將樣式文件放在上面加載。而JS恰好相反，瀏覽器剛加載完JS就會執行，若是放在前面會出現頁面卡頓的現象，因此腳本文件應該放到頁面最後加載。

CDN加速。原理與瀏覽器緩存相似，能夠經過運營商將樣式、腳本、圖片等資源文件緩存到離用戶最近的節點上，這樣用戶在發起請求時就能直接在最近的節點上找到須要的靜態資源。

反向代理。在客戶端與要交互的那臺真實服務器中間再加一臺服務器，全部的請求都由這臺機器轉發，當客戶端第一次請求資源時將資源緩存到反向代理服務器，其餘客戶端就能夠直接在反向代理服務器拿到資源，節省了轉發的時間。

服務端優化

緩存。與前端同樣，緩存是性能優化考慮的第一要素，目前流行的NoSQL數據庫都是在內存讀取的，速度會快，能夠將讀寫頻率很高但不多發生變化的數據放入緩存，能夠有效提高系統吞吐量。

異步。像日誌記錄這種必定要去作但不須要等它作完的邏輯，應該把它放到消息隊列當中，再由消費者進程逐條讀取消息隊列中的數據，慢慢執行，就像醫院的排隊取號，能夠有效解決瞬時併發較大的業務場景。

集羣。由於單臺機器的處理能力有限，若是併發請求量過大，可能沒法承受，能夠加一些機器分擔其壓力，使得請求平均分配到每臺機器上，這些由相同功能組成的機器羣就是集羣。

優化代碼。不能秉着技術不夠機器來湊的原則，回到實際代碼當中來，多數性能問題仍是代碼寫的不夠優秀，好比三條語句能搞定的數據，查了十多條，幾十行代碼算出的變量，卻沒有地方使用，用不到的數據表聯了又聯等。