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