帶有加特林的分佈式性能測試
1.簡介
在本教程中，我們將了解如何使用Gatling進行分佈式性能測試。在此過程中，我們將創建一個簡單的應用程序以使用Gatling進行測試，了解使用分佈式性能測試的原理，最後，了解Gatling提供了哪些支持來實現它。
2.加特林的性能測試
性能測試是一種測試實踐，用於評估系統在特定工作負載下的響應能力和穩定性。性能測試通常包含幾種類型的測試。其中包括負載測試，壓力測試，浸泡測試，峰值測試等。所有這些都有其自己的特定目標要實現。
但是，任何性能測試的一個共同方面是模擬工作負載，Gatling，JMeter和K6之類的工具可以幫助我們做到這一點。但是，在繼續進行之前，我們需要一個可以測試性能的應用程序。
然後，我們將為該應用程序的性能測試開發一個簡單的工作負載模型。
2.1。創建一個應用程序
在本教程中，我們將使用Spring CLI創建一個簡單的Spring Boot Web應用程序：
spring init --dependencies=web my-application接下來，我們將創建一個簡單的REST API，該API可應要求提供一個隨機數：
@RestController
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
@GetMapping("/api/random")
public Integer getRandom() {
Random random = new Random();
return random.nextInt(1000);
}
}此API沒什麼特別的-它每次調用僅返回0到999範圍內的隨機整數。
使用Maven命令啟動此應用程序非常簡單：
mvnw spring-boot:run2.2。創建工作量模型
如果我們需要將此簡單的API部署到生產中，則需要確保它可以處理預期的負載並仍提供所需的服務質量。這是我們需要執行各種性能測試的地方。工作負載模型通常標識一個或多個工作負載概要文件，以模擬實際使用情況。
對於具有用戶界面的Web應用程序，定義適當的工作負載模型可能會非常具有挑戰性。但是對於我們的簡單API，我們可以對負載測試的負載分佈進行假設。
Gatling提供了Scala DSL來創建要在仿真中測試的方案。首先，為我們之前創建的API創建一個基本方案：
package randomapi
import io.gatling.core.Predef._
import io.gatling.core.structure.ScenarioBuilder
import io.gatling.http.Predef._
import io.gatling.http.protocol.HttpProtocolBuilder
class RandomAPILoadTest extends Simulation {
val protocol: HttpProtocolBuilder = http.baseUrl("http://localhost:8080/")
val scn: ScenarioBuilder = scenario("Load testing of Random Number API")
.exec(
http("Get Random Number")
.get("api/random")
.check(status.is(200))
)
val duringSeconds: Integer = Integer.getInteger("duringSeconds", 10)
val constantUsers: Integer = Integer.getInteger("constantUsers", 10)
setUp(scn.inject(constantConcurrentUsers(constantUsers) during (duringSeconds))
.protocols(protocol))
.maxDuration(1800)
.assertions(global.responseTime.max.lt(20000), global.successfulRequests.percent.gt(95))
}讓我們討論一下基本模擬中的要點：
- 我們首先添加一些必要的Gatling DSL導入
- 接下來，我們定義HTTP協議配置
- 然後，我們通過對API的單個請求定義一個方案
- 最後，我們為要注入的負載創建一個模擬定義；在這裡，我們使用10個並髮用戶注入負載10秒鐘
使用用戶界面為更複雜的應用程序創建這種方案可能非常複雜。值得慶幸的是，Gatling附帶了另一個實用程序，稱為記錄器。使用此記錄器，我們可以通過允許它代理瀏覽器和服務器之間的交互來創建方案。它還可以使用HAR（HTTP存檔）文件來創建方案。
2.3。執行模擬
現在，我們準備執行負載測試。為此，我們可以將仿真文件“ RandomAPILoadTest.scala”放在目錄“%GATLING_HOME%/user-file/randomapi/”.請注意，這不是執行模擬的唯一方法，但肯定是最簡單的方法之一。
我們可以通過運行以下命令來啟動加特林：
$GATLING_HOME/bin/gatling.sh這將提示我們選擇要運行的仿真：
Choose a simulation number:
[0] randomapi.RandomAPILoadTest選擇模擬後，它將運行模擬並生成帶有摘要的輸出：
此外，它在目錄“％GATLING_HOME％/ results”中生成HTML格式的報告：
這只是生成的報告的一部分，但是我們可以清楚地看到結果摘要。這是非常詳細且易於遵循的。
3.分佈式性能測試
到目前為止，一切都很好。但是，回想一下，性能測試的目的是模擬實際工作負載。對於流行的應用程序來說，這可能比我們在這裡瑣碎的案例中看到的負載高出很多。如果我們在測試摘要中註意到，我們設法實現了大約500個請求/秒的吞吐量。對於處理實際工作負載的實際應用程序，這可能要高出許多倍！
我們如何使用任何性能工具來模擬這種工作量？是否真的可以僅通過單台機器注入負載來獲得這些數字？也許不是。即使負載注入工具可以處理更高的負載，底層操作系統和網絡也有其自身的局限性。
在這裡，我們必須將負載注入分佈在多台機器上。當然，像其他任何分佈式計算模型一樣，這也面臨著自己的挑戰：
- 我們如何在參與的機器之間分配工作量？
- 誰負責協調其完成和從可能發生的任何錯誤中恢復？
- 我們如何收集和匯總合併報表的結果？
分佈式性能測試的典型體系結構使用主節點和從節點來解決以下問題：
但是，如果主機崩潰了，又會發生什麼呢？解決分佈式計算的所有問題不在本教程的範圍內，但是在選擇用於性能測試的分佈式模型時，我們當然必須強調它們的含義。
4.帶有加特林的分佈式性能測試
既然我們已經了解了分佈式性能測試的必要性，那麼我們將了解如何使用Gatling實現這一目標。集群模式是Gatling Frontline的內置功能。但是，Frontline是Gatling的企業版，不能作為開源使用。 Frontline支持在本地或任何流行的雲供應商上部署注入器。
儘管如此，仍然可以通過Gatling開源實現這一目標。但是，我們將不得不承擔大部分繁重的工作。在本節中，我們將介紹實現它的基本步驟。在這裡，我們將使用我們之前定義的相同仿真來生成多機負載。
4.1。設置
我們將首先在本地或任何云供應商上創建一個控制器計算機和多個遠程工作器計算機。我們必須在所有這些計算機上執行某些先決條件。其中包括在所有工作機上安裝Gatling開源程序以及設置一些控制器機器環境變量。
為了獲得一致的結果，我們應該在所有輔助計算機上安裝相同版本的Gatling，每台計算機上均配置相同。這包括我們在其中安裝Gatling的目錄以及我們創建要安裝它的用戶。
讓我們看一下我們需要在控制器機器上設置的重要環境變量：
HOSTS=( 192.168.xx 192.168.xx 192.168.xx)並且我們還定義了將用於從中註入負載的遠程工作者計算機的列表：
GATLING_HOME=/gatling/gatling-charts-highcharts-1.5.6
GATLING_SIMULATIONS_DIR=$GATLING_HOME/user-files/simulations
SIMULATION_NAME='randomapi.RandomAPILoadTest'
GATLING_RUNNER=$GATLING_HOME/bin/gatling.sh
GATLING_REPORT_DIR=$GATLING_HOME/results/
GATHER_REPORTS_DIR=/gatling/reports/一些變量指向Gatling安裝目錄以及我們開始模擬所需的其他腳本。它還提到了我們希望生成報告的目錄。稍後我們將在哪裡使用它們。
重要的是要注意，我們假設這些機器具有類似Linux的環境。但是，我們可以輕鬆地將該過程調整為適用於Windows等其他平台。
4.2。分配負載
在這裡，我們將把相同的場景複製到我們先前創建的多台工作計算機上。有幾種方法可以將模擬複製到遠程主機。最簡單的方法是對支持的主機使用scp 。我們還可以使用shell腳本自動執行此操作：
for HOST in "${HOSTS[@]}"
do
scp -r $GATLING_SIMULATIONS_DIR/* [email protected]$HOST:$GATLING_SIMULATIONS_DIR
done上面的命令將本地主機上的目錄內容複製到遠程主機上的目錄。對於Windows用戶， Putty是PSCP（PuTTY安全複製協議）隨附的更好的選擇。我們可以使用PSCP在Windows客戶端與Windows或Unix服務器之間傳輸文件。
4.3。執行模擬
將模擬複製到工作機後，就可以觸發它們了。實現並髮用戶總數的關鍵是幾乎在所有主機上同時執行模擬。
我們可以再次使用Shell腳本自動化此步驟：
for HOST in "${HOSTS[@]}"
do
ssh -n -f [email protected]$HOST \
"sh -c 'nohup $GATLING_RUNNER -nr -s $SIMULATION_NAME \
> /gatling/run.log 2>&1 &'"
done我們正在使用ssh觸發遠程工作者計算機上的模擬。這裡要注意的關鍵是我們使用的是“無報告”選項（-nr）。這是因為我們僅在此階段才有興趣收集日誌，並且稍後將通過合併所有輔助計算機的日誌來創建報告。
4.4。收集結果
現在，我們需要在所有輔助計算機上收集由模擬生成的日誌文件。同樣，這是我們可以使用Shell腳本自動執行並可以在控制器計算機上執行的操作：
for HOST in "${HOSTS[@]}"
do
ssh -n -f [email protected]$HOST \
"sh -c 'ls -t $GATLING_REPORT_DIR | head -n 1 | xargs -I {} \
mv ${GATLING_REPORT_DIR}{} ${GATLING_REPORT_DIR}report'"
scp [email protected]$HOST:${GATLING_REPORT_DIR}report/simulation.log \
${GATHER_REPORTS_DIR}simulation-$HOST.log
done對於那些不熟悉Shell腳本的人來說，這些命令似乎很複雜。但是，當我們將它們分成幾部分時，並沒有那麼複雜。首先，我們將ssh放入遠程主機，以相反的時間順序列出Gatling報告目錄中的所有文件，並獲取第一個文件。
然後，我們將選定的日誌文件從遠程主機複製到控制器機器，並重命名它以附加主機名。這很重要，因為我們將有來自不同主機的多個具有相同名稱的日誌文件。
4.5。生成報告
最後，我們必須從在不同工作機上執行的模擬收集的所有日誌文件生成報告。幸運的是，加特林在這裡完成了所有繁重的工作：
mv $GATHER_REPORTS_DIR $GATLING_REPORT_DIR
$GATLING_RUNNER -ro reports我們將所有日誌文件複製到標準的加特林報告目錄中，並執行Gating命令生成報告。假設我們在控制器機器上也安裝了Gatling。最終報告與我們之前看到的類似：
在這裡，我們甚至都沒有意識到負載實際上是從多台機器注入的！我們可以清楚地看到，當我們使用三台工作計算機時，請求的數量幾乎增加了兩倍。但是，在現實生活中，縮放比例並不是完全線性的！
5.擴展性能測試的注意事項
我們已經看到，分佈式性能測試是一種擴展性能測試以模擬實際工作負載的方法。現在，儘管分佈式性能測試很有用，但確實有其細微差別。因此，我們絕對應該嘗試盡可能垂直地擴展負載注入能力。只有在單台機器上達到垂直限制時，才應考慮使用分佈式測試。
通常，擴展機器上的負載注入的限制因素來自底層操作系統或網絡。我們可以優化某些條件以使其變得更好。在類似Linux的環境中，負載注入程序可以產生的並髮用戶數通常受打開文件數限制。我們可以考慮使用ulimit命令增加它。
另一個重要因素涉及機器上可用的資源。例如，負載注入通常會消耗大量網絡帶寬。如果機器的網絡吞吐量是限制因素，我們可以考慮對其進行升級。同樣，機器上可用的CPU或內存可能是其他限制因素。在基於雲的環境中，切換到功能更強大的計算機相當容易。
最後，我們包含在仿真中的場景應該具有彈性，因為我們不應該始終在負載下假設積極的響應。因此，在寫關於回應的斷言時，我們應該謹慎和防禦。另外，我們應將斷言的數量保持在最低限度，以節省增加吞吐量的工作量。
六，結論
在本教程中，我們介紹了使用Gatling執行分佈式性能測試的基礎知識。我們創建了一個簡單的應用程序進行測試，在Gatling中開發了一個簡單的模擬，然後了解瞭如何在多台計算機上執行此操作。
在此過程中，我們還了解了分佈式性能測試的需求以及與之相關的最佳實踐。