背景介紹
專案越做越大，使用者量和請數量可能隨時發生井噴，如果等到系統崩潰時再補救，損失可就大了，所以得想個辦法提前預防。
想要預防，就得知道系統的哪個環比較節薄弱，頂不住壓力，還要對系統的承受能力有個全面的評估，心裡有底，好提前預防，這種評估分析預防優化等一系列手段全被效能測試涵蓋在內。
效能的指標
不同角色對效能的理解不盡相同，對於使用者來說，操作流不流暢就是效能，對於研發人員來說，介面慢不慢和頂不頂得住併發就是效能，對於運維人員來說，網路頻寬大小和資源佔用高低就是效能。
那就必要統一效能指標了，首先，使用者與研發人員都關注速度，實際上是介面的處理速度，再細一些是客戶端發起請求到收到服務端返回的時間，那就把這個指標定為響應時間吧。
我們做一款產品最需要的就是使用者，使用者越多越好，但隨著使用者量地增加，同時發起操作的使用者也越來越多，一時之間伺服器可能要處理上萬的請求，在這同一時刻處理的請求數就叫做併發數，不知何時起，處理過高併發的人成為了大家眼中的瑰寶，而併發數也成為了產品做大做強的標誌，所以併發數也要列入效能的指標。
併發數只能代表同時請求的數量很多，但並沒有賦予太多含義，與他人談論時也無法讓人整體把握系統的概況，所以需要將併發數進行變種以應對不同業務不同場景的描述，比如一天有多少人訪問，一個小時能處理多少業務，每秒處理的事務數（TPS），每秒HTTP的請求數（HPS），每秒查詢數（QPS）等等，這個指標我們為其命名為吞吐量。
除此之外，還要滿足運維人員的要求，他們需要根據系統負載、記憶體佔用、CPU佔用、網路磁碟I/O等各項指標進行分析，以便於為擴容做準備，這種一系列的硬體指標我們統稱為效能計數器。
簡單說明一下系統負載，它是指CPU當前正在執行的與等待執行的程式數總和，該數量可以體現出系統是否繁忙，我們最希望看到的是沒有程式排隊等候，所以最理想的負載數量就是CPU的數量。
四種測試型別
我們在開發時會對系統的效能有個初步的預期，然後通過模擬請求程式逐步加大請求壓力，直到你認為伺服器資源的消耗已經無法接受了，此時再觀察系統效能是否達到了預期，這種方式就是效能測試。注意，名稱雖與上述重複但不是一個概念。
我們繼續加大請求壓力，直到伺服器的某個資源已經達到飽和了，或者效能計數器中的某個指標達到了安全臨界值，簡單地說，再請求下去，系統的處理能力不但不能提高，反而會下降了。這種測試方式叫做負載測試。
還可以繼續加大壓力，不去管資源和效能指標如何，就瘋狂請求，不停地請求，直到伺服器崩潰，不能再繼續工作了，這個時候就測出了系統最大承受能力，而這種測試方式被稱為壓力測試。
沒辦法再繼續施壓了，因為伺服器已經沒有響應，那就模擬一些比較真實的場景吧，因為真實場景下的請求壓力是不均勻的，我們可以在特定環境、硬體和時間下給系統一定壓力，看看業務是否能穩定執行，這種測試方式叫做穩定性測試。
優化手段
因為一個完整的WEB請求包含前端和後端兩個部分，優化手段也從這兩部分出發。
WEB前端優化
減少請求。現在大部分請求使用的是HTTP1，每個圖片、指令碼以及樣式等資源的獲取都要客戶端單獨跑執行緒建立連線，資源過多時消耗會很大，可以將不同型別的資源各整合至一個檔案，這樣少量的請求就能拿到需要的資料。
瀏覽器快取。因為圖片、指令碼、樣式等資源使用頻率很低，沒有必要每次請求都重新下載，可以通過設定HTTP的頭部資訊將資源快取起來，這樣可以有效降低載入速度，被快取的資源需要更新時，可以通過修改資原始檔名稱的方式讓瀏覽器重新下載。
壓縮。圖片、指令碼、樣式等靜態資源一般都比較大，服務端可以將資原始檔進行壓縮，壓縮後的檔案較小，下載速度也會變快，但是前後解壓縮檔案會造成一定的壓力，所以壓縮手段要視業務情況而定。
CSS與JS順序。因為瀏覽器會載入完所有的CSS後才去渲染頁面，所以應該將樣式檔案放在上面載入。而JS剛好相反，瀏覽器剛載入完JS就會執行，如果放在前面會出現頁面卡頓的現象，所以指令碼檔案應該放到頁面最後載入。
CDN加速。原理與瀏覽器快取類似，可以通過運營商將樣式、指令碼、圖片等資原始檔快取到離使用者最近的節點上，這樣使用者在發起請求時就能直接在最近的節點上找到需要的靜態資源。
反向代理。在客戶端與要互動的那臺真實伺服器中間再加一臺伺服器，所有的請求都由這臺機器轉發，當客戶端第一次請求資源時將資源快取到反向代理伺服器，其他客戶端就可以直接在反向代理伺服器拿到資源，節省了轉發的時間。
服務端優化
快取。與前端一樣，快取是效能優化考慮的第一要素，目前流行的NoSQL資料庫都是在記憶體讀取的，速度會快，可以將讀寫頻率很高但很少發生變化的資料放入快取，可以有效提升系統吞吐量。
非同步。像日誌記錄這種一定要去做但不需要等它做完的邏輯，應該把它放到訊息佇列當中，再由消費者程式逐條讀取訊息佇列中的資料，慢慢執行，就像醫院的排隊取號，可以有效解決瞬時併發較大的業務場景。
叢集。因為單臺機器的處理能力有限，如果併發請求量過大，可能無法承受，可以加一些機器分擔其壓力，使得請求平均分配到每臺機器上，這些由相同功能組成的機器群就是叢集。
優化程式碼。不能秉著技術不夠機器來湊的原則，回到實際程式碼當中來，多數效能問題還是程式碼寫的不夠優秀，比如三條語句能搞定的資料，查了十多條，幾十行程式碼算出的變數，卻沒有地方使用，用不到的資料表聯了又聯等。
本文主要從概念和方法方面著手，意在科普知識，並沒有實踐案例，如果本文對你有幫助歡迎關注我們後續的文章。