之前在《效能測試中的各項指標告訴我們什麼》簡單介紹了一些基本的效能指標的含義，明確了我們效能測試的目標是在保證請求成功率及不超過目標請求時間的情況下，找出我們系統的最大併發量。在這篇文章中我們做些實踐，以程式設計師小張的視角來做一次效能測試。

做個最簡單的效能測試

首先我們把問題簡單化一些，假設小張從業務經理接到的一個網站開發任務，這個網站只設計了一個網頁，內容是每天公司都會更新發布的10條資訊。

好了，因為我們的假設，任務很簡單，小張三下五除二就把功能實現做完了，把程式部署到了一臺伺服器上，然後告知經理做完了。經理說，這個網站很重要，是董事長她小姨子親手抓的專案，是公司的臉面，董事長一再強調不能做成12306網站那樣一點就掛，你這程式能不能撐得住。小張說那我做下效能測試吧

小張先問了問業務經理，說我們的最大響應時間Latency是多久，業務經理有點蒙逼，說你說啥。小張清清嗓子，就是網站使用者敲入網址，等待網頁開啟，最多能等待幾秒？業務經理說，你來定吧，於是小張定了3秒。

定了3秒的最大響應時間，小張在網上找了一個測試工具（後文中我們會說有多少種測試工具），開始效能測試：

第一次測試

啟動100個執行緒，每個執行緒訪問一個頁面100次，進行壓測，

結果32秒完成1萬請求，沒有失敗，每個請求平均時長32毫秒，請問在這次測試中，QPS是多少，併發量是多少？

QPS：10000個請求/32秒=312.5請求/秒

*併發量：312.5*32=100

第二次測試

啟動1000個執行緒，每個執行緒訪問一個頁面100次，進行壓測，

結果313秒完成10萬請求，沒有失敗，每個請求平均時長3.1秒，請問在這次測試中，QPS是多少，併發量是多少？

QPS：100000個請求/313秒=319請求/秒

併發量：319*3.1=990

因為第二次測試時平均響應時長已經超過了3秒，小張看了看990這個數字，覺得系統目前最大的併發量應該在1000附近。於是跑去告訴業務經理，網站效能是最高支援1000個併發。業務經理撓了撓頭，說可是我們公司內部就有3000人啊，所有人都去看一眼豈不是掛了。小張說你覺得使用者重新整理過一次會隔多久重新整理第二次，業務經理說全部看完網頁應該是5秒，就會重新整理第二次了。小張說那就是思考時間大概是5秒，思考時間為5秒的情況下，併發1000的意思就是就是支援5000個使用者重新整理。業務經理點點頭，很滿意的走了。

這是最為簡單的一個性能測試過程的模擬。

要考慮更多

上面的那個例子，只是為了簡單體會下效能測試的大概的流程，忽略掉了很多的東西，但是現實工作中接觸到的效能測試，我們需要考慮更多：

1、系統的瓶頸

效能測試的一個重要目的就是找出系統的效能瓶頸，找到瓶頸的目的其實是為了優化或者保證能優化的可能性。從軟體開發角度來講，我們對系統瓶頸是有期望的，我們期望瓶頸出現在硬體層面，而不要出現在軟體層面。如果在效能測試中你發現伺服器的CPU、記憶體等硬體指標一直都沒有什麼變化，那就意味著肯定是瓶頸出現在網路頻寬和軟體上，那我們的工作可能就是需要調整DB連線池、OS操作控制代碼數等指標，我們的工作就是調整這些好調整的，最後調整那些不好調整的。

從上面兩次測試結果來看，雖然第二次每個請求平均時長超過3.1秒，但是其實仔細看下，相較於第一次，系統的QPS並沒有增加，說明其實在第一次測試的時候，其實就已經達到了它的瓶頸。現實的情況是，上面兩次結果其實都是筆者本機壓測百度網站的結果，而瓶頸其實是筆者機器的出口頻寬。當然在真實工作中這是不允許發生的，效能測試的客戶機到被測試機間往往要忽略網路要素，通常的做法是把他們放在統一的內網環境。

所以，在實際的測試過程中，不會像小張一樣只關心了測試客戶端的資料，必須時刻監測伺服器及中介軟體的各項效能指標，以找出系統瓶頸並分析優化以保證瓶頸出現在我們期望他出現的位置。

2、壓測的粒度

小張面臨的其實是最簡單的一種壓力測試，單機單應用測試，也就是隻有一個主機，只有一個應用，效能非常好估算。但是實際生產環境中往往是多主機多應用的環境，還有就是存在大量的鏈條式的呼叫關係，比如必須先呼叫下單服務後再呼叫支付服務。這種情況下就需要從單機單應用出發，逐漸擴充套件到叢集的測試，針對鏈條式的呼叫關係也要從單應用的測試，變為鏈路的測試，比如先單獨測試下單服務和支付服務，找到他們的最大併發數後，再構建兩個都測試的場景，測試鏈條的最大併發數。不同的軟體型別往往有不同的壓測方案，各家公司不太一樣，沒有放之四海皆準的標準。

3、壓測資料流量

當壓測的粒度定下來，真正進行壓測的時候，實際往往要進行模擬真實的資料流量。比如說要真的模擬使用者登入（壓測環境往往要針對壓測改些程式碼），模擬使用者下單，這部分往往是壓測工作中工作量最大的部分，因為要準備虛擬的使用者資料，撰寫壓測指令碼，還往往要針對壓測要修改下目標系統的程式碼以保證壓測可以正常進行（比如跳過密碼登入，關閉IP驗證等）。在傳統軟體領域，往往找一臺或者幾臺效能還不錯的測試機，執行下測試指令碼，往往也就能構建出相對應的流量。即使對使用者資料有要求，上萬條使用者資料模擬也基本夠用了。但是對於網際網路領域的大型網站來說，壓測流量資料的獲取往往是個大問題，沒有那麼多流量資料咋辦。通常的做法就是兩種：

• 線上流量回放：通過tcpcopy或者tcpdump把真實使用者的資料存下來，然後回放到壓力測試環境以獲得壓力
• 自己研發壓測平臺：自己開發流量平臺，支援構建流量模型，造虛擬流量，撰寫壓測指令碼，把壓測指令碼放到幾百臺施壓機器上執行，對壓力測試環境進行施壓。其實跟傳統軟體找機器模擬是一個意思，但是規模要大得多，所以要求自動化程度高。目前阿里PTS平臺其實就是將阿里內部的這種壓測能力輸出到阿里雲上供中小企業能夠使用

4、前端效能

僅僅針對WEB頁面測試的話，小張的測試中其實還忽略了一個要素，前端。一個網頁的訪問往往不是單純的一個請求，而是一組請求，除了html的請求還有介面請求，靜態資源請求等。如果要考慮效能損耗的話小張應該把所有請求都考慮在內對伺服器進行壓測才對。筆者現實生活中就見到過專案因為前端請求圖片過多大量佔用頻寬導致整個網站無法訪問的情況發生。當然如果在實際專案上已經做了動靜分離，可以單獨針對前端資源獲取進行服務壓力測試。但是前端效能測試還要考量的是，使用者體驗的方面，比如首屏載入時間等，這個屬於前端的領域了，與伺服器關係不大，筆者不贅述，可以點此連結瞭解