① 測試開發技術(二)——壓力測試
上一篇文章里說過，目前互聯網公司的測試開發崗位分兩類。多數的一類是既要負責業務測試、自動化測試，同時也要去開發測試框架、效率工具來輔助業務測試。這類測試開發的崗位（主要指後端的崗位）一般多少都要接觸壓力測試。
壓力測試、性能測試、負載測試、穩定性測試在網路上有很多文章介紹概念和區別，通常在項目過程中不會區分那麼多，實際項目中都是以目標為導向，通常實際項目中都會說，壓測一下看下性能，所以這里就不管詳細的概念和區別了。為了好理解，我們這里統一叫壓測，並以得到性能數據為性能測試，以觀察穩定性為穩定性測試。
性能測試和穩定性測試的相同之處在於都是使用壓測工具來進行。但目標不同，性能測試是通過壓力測試得到系統的極限畝或源性能或者和上一版本的性能對比數據。而穩定性測試則是通過壓力測試提供穩定或者變化的持續流量，來觀察系統持續運行的情況下是否存在異常。
正常情況下，一般系統先做性能測試，拿到極限性能或者性能對比數據（對於非1.0項目，性能數據一般需要和上一個版本對比）之後，再通過安全的流量持續壓測更長時間，來完成穩定性的驗證。
下面我們就具體介紹一下怎麼做性能測試和穩定性測試。
性能測試的第一步要確定目標，就是為什麼要做性能測試，要達到什麼樣的目標或者效果。比如某個首次上線的系統，性能測試主要是為了得到系統的極限性能數據；再比如，系統優化，更換了RPC協議或者消息隊列，性能測試就是為了量化此次系統優化在性能上優化的效果。另外，也不是所有的項目都需要性能測試，比如一個內部系統，用戶數和流量本身就很少，而且在未來一段時間也不會有增量，這就基本不需要性能測試。
如果是從無到有的1.0項目，因為項目還沒有上線，所迅態以只能評經驗來預估線上的流量數據；但如果是非1.0項目，就可以收集當前的線上數據。具體收集的數據如下（僅供參考，要按照實際情況來調整）：1）被測系統或模塊各類請求流量比例；2）系統或模塊目前平均、峰值、最小 qps；3）線上部署方式和規模；4）被測系統或模塊依賴能承受的QPS或者容量。
確定目標和收集完線上現有數據之後，需要根據目標和現有數據確定壓測方案，比如，每個階段通過多大並發或者流量來壓測、分幾個階段、每個階段多長時間、以及壓測過程中需要觀察和記錄哪些數據等。
同時，也要准備壓測環境，壓測的環境要盡可能的和線上一致，如果達不到，就做等比縮放。比如，一個系統有A、B兩個模塊組成，線上A部署了20台機器，B部署了5台機器，那麼壓測就可以A部署4台，B部署1台。機器和實例的數量只是一個方面，同時也要考慮機器的性能（CPU盒數、內存、磁碟、網卡等），還要考慮依賴方（如DB、緩存、消息隊列等）的部署。部署壓測環境的核心思路就是要用這套環境反應出線上環境的真實情況。
要進行壓力測試就一定要有壓測工具，一般來說壓測http或者其他開源協議可以在網上找到現成的工具，比如jmater之類的。但如果場景比較特殊，或者使用的是公司或項目的私有協議，就只能使用公司內部的工具或者自己動手開發了。
選擇好壓測工具就要構造壓測數據了。構造壓測數據主要分兩點：
第一點是要構造壓測環境系統中的數據。因為線上系統內部一定是有一定數據的，我們要盡量模擬線上就要在系統中添加相應的數據。
另一點就是要准備壓測的請求數據。這點跟選擇的壓測工具有關，一般來說分2種：
1）數據詞典， 壓測的請求提前准備好，存入文件、DB或緩存里，數據量較大的時候一般需要寫程序生成。
2）實時生成，這種是壓測工具在壓測的時候根據配置規則來實時隨機生成請求。
准備工作一切就緒，下一步就開始做壓測的執行。這時候主要就是根據壓測方案的從低到高去團歷調整壓測工具的並發數或請求數，來對目標系統或模塊進行壓測。
壓測時，要觀察CPU、內存、網路IO、磁碟空間、被壓目標日誌、依賴系統或者模塊的狀態等數，也要記錄不同並發下目標系統或者模塊處理請求的QPS和響應時間。同時也要注意有沒有內存泄漏、句柄泄漏、系統崩潰等問題。
實際上部分數據在記錄的過程中就可以初步整理出來。這里要針對上一步記錄的數據，進行匯總，主要要產出在不同並發下，上面提到的數據都是什麼情況。需要根據數據判斷出極限性能，找到這種部署情況下瓶頸在哪，以及是什麼原因造成的，為後續擴容提供依據。有些情況還需要跟以前的數據做對比，看性能提升或者下降的程度是不是符合預期。最後，把這些信息綜合匯總、分析之後，產出性能測試的報告。
通常性能測試之後拿到了性能數據之後，都會在安全的並發或者流量下持續壓測更長的時間來確保服務的穩定性。比如，筆者通常測試性能的時候，每輪可能壓測半小時到一小時（在剛開始並發或者流量較小的時候可能會更短），在得到期限性能之後，會控制極限性能時80%-%90的流量或者並發去壓測更長的時間，這個時間一般會比較長，而且多數情況下會在晚上下班前啟動，然後第二天到公司來看結果。
除了長時間通過安全流量來驗證外，有些時候在特殊場景下，也需要驗證在安全流量范圍內，流量急曾或者急降的情況下，穩定性是否有影響。或者，驗證在一定流量下，模擬某個依賴或者系統內部的模塊出現問題，執行相應預案時，對系統整體的影響是否符合預期。
當然，穩定性很多情況是異常，但更多的異常會在異常測試里去做，這里的穩定性測試是指在一定流量壓力下的穩定性測試，其他的就不做討論了。
上面介紹了壓力測試里，性能測試和穩定性測試要做什麼，那具體怎麼做呢？下面我們就通過一個實例來簡單介紹一下。
一個消息推送的系統，推送的消息就是我們日常手機APP的通知消息。這個消息通知的系統有三個介面，分別是單播（指定推送給某個人）、組播（推送給一個組，組里可能有多個人）、廣播（推送給APP所有用戶）。現在這個系統做了一個重構，更新了內部交互的RPC協議，所以要壓一下，跟之前的性能數據做個對比。另外，系統重構前，線上集群極限性能為30000 QPS。
下面，我們就按照前面的步驟，來簡單介紹一下具體怎麼做。
目標就是要得到重構後的系統性能數據，並和原有的做對比，原有的極限性能已知，大概在30000 QPS左右。
收集線上數據，比如說我們收集到單播、組播、廣播的請求比例為5：78：1；組內人數大概在300-1000；發送的消息字元數在30-100這個區間。
壓測方案要先確定部署方案，比如這個系統向上是20台機器（或者實例），壓測採用2台機器（等比縮放）。壓測機器是線上的1/10，所以我們的目標性能就是3000qps。那麼我們壓測的方案就可以如下設置：
第一輪，2個並發，5-10分鍾，主要目的是為了先驗證環境和壓測工具沒有問題；
第二輪，根據上一輪並發數和機器資源（CPU、內存、IO）的情況，調整並發到極限的一半多一些（比如，之前是2個並發，CPU佔用10%左右，內存、IO佔用都很小，那麼就以CPU的佔用作為參考來計算，1個並發大概佔用5%，那我們就可以吧並發調到10-12，目標CPU佔用是50-60%）。這其實才真正開始壓測，如果沒問題，就開始逐步加壓；
第三輪，開始逐步增加，按照實際情況一次增加2-5個並發，直到性能達到瓶頸。
這里是假設壓測工具通過調整並發數來操作壓力，主要需要看下並發對系統CPU、內存、IO的影響，根據壓測時機器的資源佔用信息來判斷增加多少並發。
確定好方案，就需要部署壓測環境了，這里要注意，盡量使用跟線上一致配置的機器。
壓測工具要根據實際業務做選擇，必要的時候需要自己開發，工具開發後面如果有機會在其他的文章里介紹，這里就不多介紹了。我們這個例子因為是系統更換內部協議，對外介面不變，所以可以使用原有壓測工具。
下面就是要構造數據：
首先，要構造系統內部的數據，比如用戶信息、設備信息、組信息，這里既要根據線上的收集到的信息來構造，比如用戶數、組的數量、組內用戶數等。這類如果方便的話可以直接在DB里插入，或者掉相應的系統API來准備。
然後就是壓測的請求數據，比如說壓測工具是用數據詞典來壓測，那麼這里我們就通過腳本，來生成壓測請求數據。這里要注意線上收集到的各個介面的佔比，即5：78：1。壓測的時候按照這個比例來提供流量。
准備工作完成，開始做壓測。
這時候要先吧各類數據觀察准備好，一般現在的互聯網大廠都有圖形化的工具來看，如果沒有也可以通過linux的一些命令來看。常用的命令有top\ps\vmstat， 這里推薦使用top來查看實時的資源情況，使用vmstat的來定時輸出當資源情況（vmstat -t 1 就是每秒輸出一次）。
准備好了觀測，那就啟動壓測工具，按照方案壓測。壓測方案上面已經介紹，這里就不重復了。
假如我們並發加到20個的時候，CPU佔用達到85%左右，處理請求達到3600qps，其他資源佔用都不足機器的一半；並發加到22個的時候，CPU佔用達到95-100，處理請求是3700qps；並發加到24，CPU打滿，處理請求3800QPS，並且出現錯誤日誌。這時候就可以停止壓測了。
數據整理，我們首先要整理一個表格或者圖標，我們這里用表格：
這個表格就是壓測產出的最核心的數據，由於CPU是明顯的性能瓶頸，表格里就不體現其他資源了，如果其他資源使用率也比較高，也要放到這個表格里，又或者瓶頸在外部依賴，也要體現出來。通過這個數據可以看出，3700QPS就是系統處理的極限，安全的流量在3600QPS。這時候就可以用17-20的並發數，長時間壓測壓測一下，看看系統整體的穩定性。
那麼性能報告怎麼寫呢？下面就給出一個比較簡單的性能報告樣例。
標題：消息推送RPC協議升級性能測試報告
一、項目背景
這里寫項目背景和目標
二、壓測環境
線上20台物理機，壓測環境使用2台物理機，配置與線上一致，具體如下：
XX核，XXG內存，萬兆網卡，硬碟 400G * 6 SSD
DB：XX主XX從XX備
三、壓測方案和數據
1. 請求比例
單播：組播：廣播 = 5：78：1
2. 壓測過程數據
3. 資源佔用圖
可以把QPS和CPU佔用使用工具（比如excel）生成一個折線圖，另外，可以把其他資源數佔用的數據圖片貼一下。
四、結論
壓測過程中，壓力達到3700qp時，內存與IO正常，CPU佔用達到98%，無錯誤日誌。壓力達到3800qps時CPU打滿，且5分鍾後開始出現錯誤日誌。因此系統在2台物理機部署極限性能為3700qps，性能瓶頸在CPU，預計線上20台機器極限性能為37000qps.
系統RPC協議升級前20台機器30000qps，升級後預計能達到37000qps，性能整體提升23%，符合預期。
上面就是一個比較簡單的報告，真實項目中瓶頸不一定是CPU，可能是其他資源，也可能是依賴的系統或者模塊，這些都需要觀察和分析壓測中的數據來得出。
壓力測試是後端測試和測試開發人員的必備技能，這篇文章只是根據筆者的經驗針對壓力測試進行的總結，不能覆蓋所有壓測場景，僅給大家做個參考。更多的是需要我們根據系統的實際情況去探索和實踐。
② 如何使用MySQL自帶的性能壓力測試工具mysqlslap
使用--auto-generate-sql參數表示用mysqlslap工具自己生成的SQL腳本來測試並發弊返壓力
mysqlslap --auto-generate-sql -uroot -p123456
並發測試，使用–concurrency來模擬並發連接，連接數可以多個，用逗號隔開
mysqlslap --auto-generate-sql --concurrency=100 -uroot -p123456
mysqlslap --auto-generate-sql --concurrency=50,100 -uroot -p123456
使用--iterations模擬迭代測試，用於需要多次執行測試得到平均值。
mysqlslap --auto-generate-sql --iterations=5 -uroot -p123456
使用--engine測試不同的存儲引擎的性能進行對比
mysqlslap --auto-generate-sql --concurrency=50,100 --iterations=5 --engine=myisam,innodb -uroot -p123456
--query=name,-q 指定自定義腳本執行測試，例如可以調用自定義的一個存儲過程或者租猛飢sql語句來執行測試。--create-schema 指定自定義的測試資料庫名知吵稱，
mysqlslap --auto-generate-sql --concurrency=50,100 --create-schema="landclash" --query="call landclash.sp_player_getname(34);" --number-of-queries=5000 -uroot -p123456
③ 性能測試到底該怎麼做
作為一名開發者，我們最長聽到的就是編程界的三高：
高性能、高並發、高可用。
聽起來非常高大上，但是性能到底如何呢？又該如何評定呢？
這次我們談一談性能測試，看一看到底什麼樣才叫做高性能。
本文主要從以下幾個方面進行討論。
（1）性能測試是什麼？
（2）為什麼需要性能測試？
（3）性能測試如何做？
（4）有哪些性能測試的工具
老馬曾經說過，你想理解一件事物，首先必須先定義它。
這里直接引用一下網路中的定義：
性能測試的定義也不難理解，往往定義本身闡述了性能測試的作用。
如果你是一名開發、測試，平時接手過不少需求，可能性能測試接觸的也不多。
每一個需求，都有對應的功能性需求和肺功能性需求。
功能性需求是產品需求文檔中最直接的，需要實現的功能目標。簡稱，能用就行。
非功能性需求則要寬泛的多，架構設計是否合理？是否便於後期拓展？是否便於監控？代碼實現是否優雅？文檔注釋是否完整？
就像你寫了弊談一隻鳥，鳥頭做螺旋槳非能飛起來，但是在架構設計上可能是不合理的。
飛起來
一個查詢功能，用戶點擊查詢，10S 種才返回數據，功能上是滿足的，但是性能上是不能接受的。
線上的交易功能平時各方面都很棒，節假日高峰期直接系統就癱瘓了。
那如何避免這些問題出現在生產上呢？
這就需要上線之前，首先做好對應的性能測試，避免再生產上出現問題，帶來嚴重的生產事故。
性能要高，性能要硬，性能測試，又高又硬！
又高又硬
做一件事情之前，我們首先要確定好自己的目標。
性能測試，到底要測試什麼？
有些類似於開發過程中的需求分析，常見的測試指標如下。
響應時間是指某個請求或操作從發出到接收到反饋所消耗的時間，包括應用伺服器（客戶端）處理時間、網路傳輸時間以及資料庫伺服器處理時間。
作為用戶而言，在頁面點擊查詢，等待了多久才能獲取結果，這個就是響應時間。
用戶不關心你後端經過了多少個服務，慢就是原罪。
對於微服務系統，鏈路監控就顯得比較重要。可以幫助我們快速定位到底慢在哪裡。
TPS（Transaction Per Second）是指單位時間（每秒）系統處理的事務量。
我看網上還有很多類似的概念：點擊量/點擊率、吞吐量/吞吐率、PV/UV，這里不做贅述。
個人看來本質上 TPS/QPS 就是去壓測你應用的極限，當訪問量較大的時候，程序能否活下來？
這里主要涉及到兩個概念：高性能和高可用。
我們後面會簡單討論下這兩點。
明確了測試指標之後，就需要進行測試的准備。
環境准備：比如你想壓測資料庫，那就需要准備對應配置的資料庫資源。
腳本的准備：數據初始化腳本，調用腳本等。
這個可以類比開發過程中的代碼開發。
ps: 性能壓測一般不是很常用，所以環境准備流程會比較長，這一點需要注意。
當進行測試之後，測試的結果一定要給出一份報告出來。
是否通過壓測要求？
最高的 QPS 是多少？
這樣開發可以根據這份報告進行相應的優化。
提升性能的內容寫一本書也不為過，這里簡單羅列一些最常用的幾點：
（1）慢 SQL
一般程序如果響應時間較長，可以首先看一下慢 SQL。
看下是否需要增加索引，或者進行 SQL 優化。
（2）緩存
針對查詢，性能提升最顯著的就是引入緩存。
當然，引入緩存會使架構變得復雜，這一點要結合自己的實際業務。
（3）硬體升級
如果程行磨序優化的空間比較小，可以考慮升級一下硬體資源。租帶碰
比如伺服器配置翻倍，資料庫配置翻倍。
什麼？你說公司沒錢升級？
沒錢升級做什麼壓測？
這個時候測試報告的作用就顯露了，直接用數據說話。
直接說 QPS 達不到生產要求，程序優化的空間很小，推薦硬體升級配置，升級到多少。
做人，要以德服人。
做測試，要用數據說話。
以德服人
測試最常用的工具當屬 jmeter。
除此之外，還有一些其他的工具：
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面對幾個工具做下簡單介紹
Apache JMeter 可以用於測試靜態和動態資源(Web動態應用程序)的性能。
它可以用於模擬伺服器、伺服器組、網路或對象上的負載，以測試其強度或分析不同負載類型下的總體性能。
將負載測試集成到開發工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
從12.55版本開始，您可以運行您的JMeter腳本，並在任何性能測試中集成JMeter和附加的腳本類型。
ps: 這個設計理念就非常好，可以和成熟的工具進行整合。站在巨人的肩膀上。
QALoad是客戶/伺服器系統、企業資源配置（ERP）和電子商務應用的自動化負載測試工具。
QALoad可以模擬成百上千的用戶並發執行關鍵業務而完成對應用程序的測試，並針對所發現問題對系統性能進行優化，確保應用的成功部署。
ps: 這個工具本人沒有接觸過。
SilkPerformerV可以讓你在使用前，就能夠預測企業電子商務環境的行為—不受電子商務應用規模和復雜性影響。
可視化的用戶化、負載條件下可視化的內容校驗、實時的性能監視和強大的管理報告可以幫助您迅速將問題隔離，這樣，通過最小化測試周期、優化性能以及確保可伸縮性，加快了投入市場的時間，並保證了系統的可靠性。
作為 DevOps 方法的一部分，IBM Rational Performance Tester 幫助軟體測試團隊更早、更頻繁地進行測試。
它驗證 Web 和伺服器應用程序的可擴展性，確定系統性能瓶頸的存在和原因，並減少負載測試。
您的軟體測試團隊可以快速執行性能測試，分析負載對應用程序的影響。
ps: 這一款工具有 IBM 提供，質量值得信賴。
這么多工具可供使用，相信讀到這里的小夥伴已經找到了自己心儀的測試工具。
別急，下面專門為做 java 開發的小夥伴們推薦一款性能測試工具。
男人有男人的浪漫，開發者當然也要有開發者的浪漫。
【男人的浪.jpg】
作為一名開發者，老馬平時單元測試使用 junit 最多。
所以一直希望找到一款基於 junit 的性能壓測工具，後來也確實找到了。
@JunitPerfConfig 指定測試時的屬性配置。(必填項)
使用如下：
@JunitPerfRequire 指定測試時需要達到的要求。(選填項)
使用如下：
對應的測試報告生成方式也是多樣的，也允許用戶自定義。
基於控台日誌：
或者基於 HTML:
junitperf
本文對性能測試做了最基本的介紹，讓小夥伴們對性能壓測有一個最基本的理解。
測試和開發一樣，都是一件費時費力，而且需要認真做才能做好的事情，其中的學問不是一篇就能說清的。
性能測試工具也比較多，本文重點介紹了專門為 java 開發者打造的 junitperf 工具。
下一節我們將從源碼角度，講解一下 junitperf 的實現原理。
我是老馬，期待與你的下次重逢。
開源地址：https://github.com/houbb/junitperf
④ 如何用Jmeter做壓力測試
在「伺服器名稱或ip」設置127.0.0.1，埠號設置:8080，「方法」設置post，路徑設置網站登錄的地址，如「/exam/operatorAction」。
登錄需傳入用戶、密碼。在「同請求一起發送參數」列表中添加參數。參數值根據web應用設置。如login_user=0001;login_password=1;actFlag=login。
一般網站登錄後，在tomcat中生成了session，之後訪問其他頁面將無需再次登錄悉臘，前提是瀏覽器需支持cookie。在jmap中也同樣，如要繼續訪問其他頁面，還需做下面關鍵的設置。
Apache JMeter
是Apache組織開發的基於Java的壓力測試工具。用於對軟體做壓力測試，它最初被設計用於Web應用測試，但後來擴展到其他測試領域。 它可以用於測試靜態和動態資源，例如靜態文件、Java小服務程序、CGI 腳本、Java 對象、數睜余滑據庫、FTP伺服器， 等等。JMeter 可以用於對伺服器、網路或對毀芹象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。
⑤ 壓測工具JMeter的使用
性能壓測工具，在我們項目開發過程中肯定免不了要經常使用，來檢測我們完成的介面或者整舉哪體服務的抗壓水平。Apache提供了個 ab 命令，可以進行壓測功能，只不過功能相對簡單，有時候很難滿足我們的測試需求。
所以，這里介紹下Apache的另一款壓測工具 JMeter，它是Apache組織開發的開源項目，設計之初是用於做性能測試的，同時它在實現對各種介面的調用方 面做的比較成熟，因此，常被用做介面功能測試和性能測試。
本次壓測模擬的流程是：請求先訪問登錄介面，成功後通過返回信息拿到用戶ID，再將用戶ID作為參數訪問商品下單的介面。壓力測試規則是每秒1000的並發請求，執行1次，也就是執行1s。
PS：下方涉及到的三個變數 NAME、PASSWORD、USER_ID 它們是需要用 {} 來包裹的，我下邊寫錯了，寫成了 () 包裹鄭簡的了。哈哈，我實在是懶得挨個截圖改了，在這里說明下，明白原喊答褲理就好
⑥ 性能測試工具 wrk 使用教程
被面試官經常問到之前開發的系統介面 QPS 能達到多少，經常給不出一個數值，支支吾吾，導致整體面試效果降低？
原因基本是一些公司中，做完功能測試就完了，壓根不會有性能測試這一步，或者說並發量較少，沒有必要進行性能測液指試，亦或者，交給測試人員後，只要整體問題不大，測試報告一般也是不會再給後端人員看的，這就導致我們在面試的時候，場面一度尷尬 ！！！
其實，不單單是針對面試，作為一名後端開發者，我們在完成一個介面開發後，在交給測試工程師之前，經常也會想知道，自己寫的這個介面的性能如何呢？吞吐量能達到多少？QPS（Query per second 每秒處理完的請求數） 能達到多少呢？
這個時候，我們就需要藉助一些常用的性能測試工具，如 Apache ab, Apache JMeter (互聯網公司用的較多)，LoadRunner 等消燃。
我們今天主要說一說輕量級性能測試工具 wrk 。
一、什麼是 wrk
二、 wrk 的優勢&劣勢
三、wrk 安裝
四、如何使用
五、總結
六、參考文檔
七、贈送面試&學習福利資源
摘自官方 GitHub 上的英文介紹：
翻譯一下：
wrk 是一款針對 Http 協議的基準測試工具，它能夠在單機多核 CPU 的條件下，使用系統自帶的高性能 I/O 機制，如 epoll，kqueue 等，通過多線程和事件模式，對目標機器產生大量的負載。
在說 wrk 的優勢之前，瞅一下 wrk 的 GitHub Star 數，也能側面反映下它的可靠性：
Wow ! 截止筆者截圖為止, Star 數已經達到了 19742 !!!
再來說說 wrk 的優勢：
wrk 目前僅支持單機壓測，後續也不太可能支持多機器對目標機壓測，因為它本身的定位，並不是用來取代 JMeter, LoadRunner 等專業的測試工具，wrk 提供的功能，對我們後端開發人員來說，應付日常介面性能驗證還是比較友好的。
wrk 只能被安裝在類 Unix 系統上，所以我們需要一個 Linux 或者 MacOS 環境。Windows 10 安裝需要開啟自帶的 Ubuntu 子系統。
依次執行如下命令：
依次執行如下命令：
Mac 系統也可以通過先編譯的方式來安裝，但是更推薦使用 brew 的方式來安裝, 步驟如下：
Windown 10 需要在 Windows 功能 里勾選 適用於 Linux 的 Windows 子系統 , 然後通過 bash 命令切換到 Ubuntu 子系統。接下來，參考 3.1.1 Ubuntu 的操作系通中，安裝 wrk 的步驟。
命令行中輸入命令：
輸出如上信息，說明安裝成功了！
安裝成功了，要如何使用呢？
這條命令表示，利用 wrk 對 www..com 發起壓力測試，線程數為 12，模擬 400 個並發請求，持續 30 秒。
除了上面簡單示例中使用到的子命令參數，拿埋虛 wrk 還有其他更豐富的功能，命令行中輸入 wrk --help , 可以看到支持以下子命令：
翻譯一下：
執行壓測命令:
執行上面的壓測命令，30 秒壓測過後，生成如下壓測報告：
我們來具體說一說，報告中各項指標都代表什麼意思：
可以看到，壓測報告還是非常直觀的！
您可能有疑問了，你這種進行 GET 請求還湊合，我想進行 POST 請求咋辦？而且我想每次的請求參數都不一樣，用來模擬用戶使用的實際場景，又要怎麼弄呢？
對於這種需求，我們可以通過編寫 Lua 腳本的方式，在運行壓測命令時，通過參數 --script 來指定 Lua 腳本，來滿足個性化需求。
wrk 支持在三個階段對壓測進行個性化，分別是啟動階段、運行階段和結束階段。每個測試線程，都擁有獨立的Lua 運行環境。
啟動階段:
在腳本文件中實現 setup 方法，wrk 就會在測試線程已經初始化，但還沒有啟動的時候調用該方法。wrk會為每一個測試線程調用一次 setup 方法，並傳入代表測試線程的對象 thread 作為參數。setup 方法中可操作該 thread 對象，獲取信息、存儲信息、甚至關閉該線程。
運行階段：
結束階段：
done() 方法在整個測試過程中只會被調用一次，我們可以從給定的參數中，獲取壓測結果，生成定製化的測試報告。
自定義 Lua 腳本中可訪問的變數以及方法：
變數：wrk
以上定義了一個 table 類型的全局變數，修改該 wrk 變數，會影響所有請求。
方法：
上面三個方法解釋如下：
調用 POST 介面：
注意: wrk 是個全局變數，這里對其做了修改，使得所有請求都使用 POST 的方式，並指定了 body 和 Content-Type頭。
自定義每次請求的參數：
在 request 方法中，隨機生成 1~10000000 之間的 uid，並動態生成請求 URL.
每次請求前，延遲 10ms:
請求的介面需要先進行認證，獲取 token 後，才能發起請求，咋辦？
上面的腳本表示，在 token 為空的情況下，先請求 /auth 介面來認證，獲取 token, 拿到 token 以後，將 token 放置到請求頭中，再請求真正需要壓測的 /test 介面。
壓測支持 HTTP pipeline 的服務：
通過在 init 方法中將三個 HTTP請求拼接在一起，實現每次發送三個請求，以使用 HTTP pipeline。
本文中，我們學習了輕量級性能測試工具 wrk, 如何安裝，以及具體的使用方法，包括通過 Lua 腳本來個性化定製請求等。希望讀完本文，能對您有所幫助哦！