As is widely known, JMeter is a poorly optimized tool. This is due in part to the use of Virtual Threads. By comparison, golang (and the k6 tool that runs on it) uses goroutines, while the Kotlin language has coroutines.
Since JMeter is relatively old for a performance testing tool, several elements should be taken into account when creating and running test scenarios. We have divided them into two sections - scenario optimization (designing scenarios) and the JVM (running tests).
JMeter script optimization
Before running the target test, make changes to the script to reduce RAM consumption on the server.
- Use the latest version of Jmeter.
- In testing, it is suggested to use
Regexp Variable Extractorsto extract data from the server response. - Assertions are used sensibly - not everything must be included, only the most important elements of the response.
- All listeners should be disabled, e.g.
View Results TreeorSummary Report- they are too resource intensive. - All
Debug Samplersshould be disabled. - The best optimized language in JMeter is
Groovy. If possible, it should be used instead of, for example,Beanshell. - If the tests include
Transaction Controller, theGenerate Parent Sampleoption should be unchecked. - When running the tests through
CLIor Redline13, theJVMoptimization configuration should be entered.
JVM optimization
The next step is already optimizing the JVM itself, which runs under the JMeter "shell". It is not recommended to run tests from the UI due to the considerable RAM consumption - therefore, it is better to run scenarios from the console.
Someone might ask "What if I want to see the results on the fly?". We answer briefly: invest the time to set up tools locally to observe real time results. InfluxDB + Grafana can serve this purpose.
We run tests in the console along the lines of the following command.
java -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -Xms512m -Xmx747520m -d64 -jar C:\jmeter\bin\ApacheJMeter.jar -n -t scenario.jmx results.jtl -e -o results
The parameters inside the command are divided into two sections - JMeter parameters and JVMa parameters.
JVMa parameters
-XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -Xms512m -Xmx747520m -d64
| Parameter | Description |
|---|---|
| -XX:+UseConcMarkSweepGC | Forces the use of CMS garbage collector. This reduces overall throughput, but leads to much faster CPU time. |
| -XX:+DisableExplicitGC | It prevents applications from forcing costly garbage collection and helps avoid unexpected interruptions. |
| -Xms512m | Minimum memory allocation pool for JVM marked in MB. |
| -Xmx747520m | The maximum memory allocation pool for the JVM denoted in MB. If we run the tests on an instance having 32GB, the tem parameter will take the value -Xmx24576m because we assume that 8GB will be allocated for other server processes. Therefore, we are left with 24GB which gives us 24576MB (since 1GB=1024MB)The maximum memory allocation pool for the JVM denoted in MB. If we run the tests on an instance having 32GB, the tem parameter will take the value -Xmx24576m because we assume that 8GB will be allocated for other server processes. Therefore, we are left with 24GB which gives us 24576MB (since 1GB=1024MB). |
| -d64 | If you have a 64-bit operating system, use this parameter to explicitly tell the JVM to run in 64-bit mode. |
JMeter parameters.
At this stage it is worth noting that we are not running either the .bat or .sh file. Instead, I use the .jar version - because we are running a java program.
-jar C:\jmeter\bin\ApacheJMeter.jar -n -t scenario.jmx -l results.jtl -e -o results
| Parameter | Description |
|---|---|
| -jar C:\jmeter\bin\ApacheJMeter.jar | Indication of JMeter implementation in .jar format. |
| -n | This specifies JMeter is to run in cli mode. |
| -t scenario.jmx | Name of JMX file that contains the Test Plan. |
| -l results.jtl | Name of JTL file to log sample results to. |
| -e | Generate report dashboard after load test. |
| -o results | Output folder where to generate the report dashboard after load test. Folder must not exist or be empty. |
With the tips above, running JMeter tests will be better optimized, and the team will avoid RAM problems. However, if the advice above fails, you may be left with nothing but distributed testing.
Top comments (0)