淺談Web效能測試
什麼是效能測試？web效能應該注意些什麼？
效能測試，簡而言之就是模仿使用者對一個系統進行大批量的操作，得出系統各項效能指標和效能瓶頸，並從中發現存在的問題，通過多方協助調優的過程。而web端的效能測試應該注意的指標有：使用者操作的響應時間、系統的吞吐量（TPS）、系統的硬體資源情況（CPU、硬碟、磁碟）、網路資源佔用情況等。
web效能測試之HTTP請求
- 關於效能測試中，HTTP請求類的效能指標都需要我們去關注些什麼？
- 響應時間，這裡的響應時間一定得是前端+後端的響應時間，我們慣性的思維都是隻關注後端服務的響應時間，其實前端的響應時間也是須考慮在內的。
- 併發測試的相應資料，這部分也得考慮前端資料，這只是一個大概的補充，因為具體的系統需要的資料不一樣，其中也不乏包括響應時間。
- 其中，前端的響應時間都涉及到哪些環節呢？
- DNS解析
- 各種請求的連線
- TLS的建立
- 位元組流的傳送
- 另外，後端響應時間涉及的環節：
- 等待（前端請求）
- 接收資訊流
- 返回響應資料
這其實就是一個比較完整的web端請求所需要的環節，而響應時間就是指的這個請求的過程所花費的時間。這部分時間就是一個使用者在操作的時候所等待的時間，所以使用者所能接受的時間範圍恰好是效能測試所關注的時間範圍。通常使用者所能接受的系統響應時間是3-5s，若大於這個時間節點，將會使使用者失去耐心，取消對系統的操作。
web效能測試之Jmeter
Jmeter屬於一個非常實用的測試工具，在效能測試當中也佔有一個非常重要的位置。通常jmeter在效能測試過程中，涉及到的基本是直接對接的後端服務，針對前端的響應基本不會涉及，所以用jmeter來對一個web系統進行效能測試時，很難去捕獲到前端的響應資料。但是後端響應資料獲取起來非常的便捷，其中就包括：併發數、平均響應時間、錯誤率、吞吐量等等，如下圖：
那麼，關於前端的響應資料，我們該用什麼方法去獲取呢？接下來講的一種方法，就是利用LR來進行。
web效能測試之Loadrunner
Loadrunner則是屬於企業軟體，這就奠定了它功能繁多，用途廣泛的基礎。LR算是一個大型的效能測試工具了，但是平常使用也還是其基本的一些功能。LR在使用者介面互動上進行了注重，也就是我們之前提到的前端的響應資料，利用LR能夠彌補jmeter無法涉及到的前端響應時間這部分
web效能測試之響應時間
結合以上提及到的響應時間，它所涉及到的有兩個部分，一是前端，二是後端：
關於整體系統壓測策略
那提及到系統壓測的策略，其實是想提一下怎樣去利用單節點和叢集這兩種方案。通常的壓測，都是採用的單節點來進行的，這樣“以小見大”的方法不為一個不可採取的方法，但是這其中還是會造成很多的誤差。還有就是，單節點的壓測容易壓低整個系統的效能指標，因為無法充分的利用系統資源。
而叢集壓測，在環境部署上是一個複雜點，但是能夠充分利用系統已有資源，這樣得出的資料能夠更加真實有效。在有過量的時間時，可以講單節點和叢集的壓測資料進行對比，這樣就能發現其中存在的差異。
關於效能測試日誌
效能測試中，日誌是非常能夠反應出測試工作中問題所在的一個環節，通過檢視日誌來定位問題是一個繁雜但是極為可靠的方式。
此類測試中，都會涉及到哪些日誌呢？
- Jmeter端日誌
- HTTP端打到Nginx端的日誌，這層會涉及到來源IP、請求地址、響應時間等。
- Tomcat層日誌
- Server層日誌
關於OS層資料監控
CPU監控，通常的指標是CPU使用率不能超過80%，這樣給系統預留一個緩衝的範圍。這裡提及一點，就是其中涉及到多核CPU的情況，嚴謹的人會去關注每核CPU的使用情況，因為很多時候多核CPU的利用並不是均衡的，整體的CPU使用情況不能反映出單核的使用情況，容易造成誤導。
JVM層監控，這主要是去監控執行緒，其中包含單執行緒、多執行緒，同步執行緒、非同步執行緒。關於同步執行緒和非同步執行緒，是一個系統中比較關注的點，假如：一個系統處理事務時，採用的是同步執行緒，很多事務會等待處理造成阻塞，那麼這樣的系統處理速度就會受到很大的限制，會被視為一個不合格的系統。
以上算是記錄一下從多方面去考慮web效能測試的各個點，從而使測試結果更加真實有效。