How set port jmeter in jmeter 4 and 5? - jmeter

I run two tests of two different machines, the first one runs the second is KO,
can you explain why I have two different ports (4446 and 4445) at each test launch?
The first test is OK:
Creating summariser t / TU_27h35.csv -e -o / report / TU_27_02 Created the tree successfully using /home/ouitead/scriptsJmeter/TdC_15012019/all_tu.jmx
Starting the test # Wed Feb 27 15:49:06 CET 2019 (1551278946720)
Waiting for possible Shutdown / StopTestNow / Heapdump message on port 4446
summary + 15 in 00:00:25 = 0.6 / s Avg: 869 Min: 504 Max: 1296 Err: 0 (0.00%) Active: 2 Started: 8 Finished: 6
summary + 19 in 00:00:30 = 0.6 / s Avg: 527 Min: 185 Max: 868 Err: 0 (0.00%) Active: 1 Started: 15 Finished: 14
summary = 34 in 00:00:55 = 0.6 / s Avg: 678 Min: 185 Max: 1296 Err: 0 (0.00%)
summary + 8 in 00:00:30 = 0.3 / s Avg: 704 Min: 151 Max: 1963 Err: 0 (0.00%) Active: 1 Started: 18 Finished: 17
summary = 42 in 00:01:25 = 0.5 / s Avg: 683 Min: 151 Max: 1963 Err: 0 (0.00%)
summary + 8 in 00:00:24 = 0.3 / s Avg: 344 Min: 206 Max: 619 Err: 0 (0.00%) Active: 0 Started: 20 Finished: 20
summary = 50 in 00:01:49 = 0.5 / s Avg: 629 Min: 151 Max: 1963 Err: 0 (0.00%)
Tidying up ... # Wed Feb 27 15:50:56 CET 2019 (1551279056488)
... end of run
The second test is KO:
Created the tree successfully using /scriptsJmeter/all_tu.jmx
Starting the test # Wed Feb 27 15:50:10 CET 2019 (1551279010436)
Waiting for possible Shutdown / StopTestNow / Heapdump message on port 4445
summary = 0 in 00:00:00 = ****** / s Avg: 0 Min: 9223372036854775807 Max: -9223372036854775808 Err: 0 (0.00%)
Tidying up ... # Wed Feb 27 15:51:59 CET 2019 (1551279119074)
... end of run
Thank you for your help.

Port 4445 is controlled by property jmeterengine.nongui.port and increment port number in case port is used (by another execution for example)
JMeter CLI mode will listen for commands on a specific port (default 4445, see the JMeter property jmeterengine.nongui.port). JMeter supports automatic choice of an alternate port if the default port is being used (for example by another JMeter instance). In this case, JMeter will try the next higher port, continuing until it reaches the JMeter property jmeterengine.nongui.maxport) which defaults to 4455.

Related

Jmeter load testing giving different values

when I am load testing for 100 users at rampup of 2 seconds I am getting different values for same users and same ramp up time why is this happening can anyone help?
in remote server
1st time
summary = 100 in 00:00:03 = 31.7/s Avg: 1916 Min: 985 Max: 2737 Err: 0 (0.00%)
2nd time
summary + 1 in 00:00:01 = 1.5/s Avg: 260 Min: 260 Max: 260 Err: 0 (0.00%) Active: 22 Started: 22 Finished: 0
summary + 99 in 00:00:02 = 65.6/s Avg: 113 Min: 18 Max: 371 Err: 0 (0.00%) Active: 0 Started: 100 Finished: 100
summary = 100 in 00:00:02 = 45.9/s Avg: 114 Min: 18 Max: 371 Err: 0 (0.00%)
3rd time
summary + 1 in 00:00:01 = 2.0/s Avg: 92 Min: 92 Max: 92 Err: 0 (0.00%) Active: 14 Started: 14 Finished: 0
summary + 99 in 00:00:02 = 58.7/s Avg: 26 Min: 13 Max: 92 Err: 0 (0.00%) Active: 0 Started: 100 Finished: 100
summary = 100 in 00:00:02 = 45.5/s Avg: 26 Min: 13 Max: 92 Err: 0 (0.00%)
Normally tests should be repeatable which means that re-running the test should produce the same results.
Your test case is kind of specific, it looks like a spike test, for the first time response times are quite high and 2nd and 3rd execution they're going down. I can think of the following possible reasons:
First time response times are high because caches are not warmed up
Your application might have some optimization mechanisms like JIT
If you run exactly the same test it might be the case your system under test caches responses in different levels (operating system memory, database query cache, 3rd-party solutions like memcached
In order to have more repeatable results and better picture I would suggest:
increasing your test duration to i.e. 10 minutes
increasing your load gradually, i.e. change ramp-up time to 5 minutes
implementing monitoring of the system under test using i.e. JMeter PerfMon Plugin

Error during jmeter traffic execution. "Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock."

I'm using jmeter to perform traffic performance test.
During traffic execution jmeter returns some errors that increase total execution error.
Can someone help me?
These is the error:
summary + 4858 in 00:00:16 = 304.8/s Avg: 481 Min: 9 Max: 4536 Err: 0 (0.00%) Active: 179
Started: 659 Finished: 480
summary + 12502 in 00:00:30 = 414.9/s Avg: 426 Min: 8 Max: 4147 Err: 0 (0.00%) Active: 178
Started: 1908 Finished: 1730
summary = 17360 in 00:00:46 = 376.8/s Avg: 441 Min: 8 Max: 4536 Err: 0 (0.00%)
summary + 12432 in 00:00:30 = 416.2/s Avg: 442 Min: 9 Max: 4208 Err: 0 (0.00%) Active: 203
Started: 3160 Finished: 2957
summary = 29792 in 00:01:16 = 392.3/s Avg: 442 Min: 8 Max: 4536 Err: 0 (0.00%)
Dec 14, 2021 5:11:43 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 24.
Dec 14, 2021 5:11:43 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file
lock.
**Dec 14, 2021 5:12:13 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 24.
Dec 14, 2021 5:12:13 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file
lock.**
From my very limited understanding of C language Unix error 24 stands for "too many open files"
#define EMFILE 24 /* Too many open files */
You can check the current limit by running ulimit -n command
If you have superuser permissions you can ramp-up this limit according to the number of threads you're using
If you don't have root access - the only solution would be finding another machine and running your JMeter test in distributed mode

Jmeter summary report on command line

Jmeter non-gui mode generates real time Test Results in the below format:
summary = 1649731 in 00:10:06 = 2721.2/s Avg: 47 Min: 9 Max: 16027 Err: 112 (0.01%)
summary + 63699 in 00:00:30 = 2123.3/s Avg: 64 Min: 12 Max: 2080 Err: 4 (0.01%) Active: 192 Started: 193 Finished: 1
summary = 1713430 in 00:10:36 = 2693.0/s Avg: 47 Min: 9 Max: 16027 Err: 116 (0.01%)
summary + 62509 in 00:00:30 = 2083.6/s Avg: 66 Min: 11 Max: 2034 Err: 1 (0.00%) Active: 192 Started: 193 Finished: 1
summary = 1775939 in 00:11:06 = 2665.6/s Avg: 48 Min: 9 Max: 16027 Err: 117 (0.01%)
summary + 69708 in 00:00:30 = 2323.5/s Avg: 45 Min: 9 Max: 2074 Err: 4 (0.01%) Active: 123 Started: 193 Finished: 70
summary = 1845647 in 00:11:36 = 2650.9/s Avg: 48 Min: 9 Max: 16027 Err: 121 (0.01%)
What is summary + and summary = ?
Summary + are incremental for the latest summariser period
Summary = are cumulative for the above Summary+
summary + 63699 in 00:00:30 = 2123.3/s
summary = 1713430 in 00:10:36 = 2693.0/s
Example 63699 in 00:00:30 = 2123.3/s means that in 30seconds Jmeter have sent 63699 requests to the server with an average throughput of 2123 requests per second.
The next iteration will start from the ahead of the cumulative time of the above summary. Ex: 00:11:06 = (00:00:30 + 00:10:36)
As per Top 2 Techniques to Get JMeter Test Results in non-GUI mode
Here’s an example of what you get from the default summariser:
summary + 41 in 15.4s = 2.7/s Avg: 2234 Min: 383 Max: 6974 Err: 0 (0.00%)
summary + 57 in 21.5s = 2.6/s Avg: 2548 Min: 618 Max: 4528 Err: 0 (0.00%)
summary = 98 in 32.5s = 3.0/s Avg: 2416 Min: 383 Max: 6974 Err: 0 (0.00%)
summary + 108 in 21.8s = 5.0/s Avg: 1291 Min: 229 Max: 6317 Err: 0 (0.00%)
summary = 206 in 52.5s = 3.9/s Avg: 1827 Min: 229 Max: 6974 Err: 0 (0.00%)
The lines with summary + are incremental for the latest summariser period, the lines with summary = are cumulative. The above was with a summariser period of 20 secs, the actual periods can sometimes be longer than the specified period and the length of the very first period is somewhat random. You get the throughput statistics as well as average, min and max response times, and how many errors were detected (assuming your JMeter test plan has assertions to detect errors).
If the JMeter's summariser output doesn't seem too informative to you consider running your JMeter test using Taurus tool as a wrapper, it has console reporter which prints current metrics right in your terminal:
You can also configure Backend Listener to store results to InfluxDB and plot them using Grafana, an example dashboard can look like:

Why the number of threads growing higher than expected?

I have a test case with just one HTTP request. The number of threads and Ramp Up period is set to 30. And i planning to do the test for 600 seconds.
But looking at the JMeter output, i could see a huge number of requests generated. Why is this so? I am expecting only 60 threads in a minute to generate. Can someone suggest me how to do this?
S:\roshTests\apache-jmeter-3.1\bin>jmeter -n -t
S:\roshTests\LivePerformance\June1\PPS-Proxy\catalog\catalog.jmx -l
S:\roshTests\LivePerformance\June1\PPS-Proxy\catalog\Output\results.csv
Writing log file to: S:\roshTests\apache-jmeter-3.1\bin\jmeter.log
Creating summariser <summary>
Created the tree successfully using S:\roshTests\LivePerformance\June1\PPS-Proxy\catalog\catalog.jmx
Starting the test # Fri Jun 02 05:18:04 IDT 2017 (1496369884546)
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary + 377 in 00:00:25 = 15.3/s Avg: 766 Min: 106 Max: 3114 Err: 198 (52.52%) Active: 25 Started: 25 Finished: 0
summary + 1364 in 00:00:30 = 45.5/s Avg: 647 Min: 144 Max: 4385 Err: 1180 (86.51%) Active: 30 Started: 30 Finished: 0
summary = 1741 in 00:00:55 = 31.9/s Avg: 673 Min: 106 Max: 4385 Err: 1378 (79.15%)
summary + 985 in 00:00:30 = 32.8/s Avg: 643 Min: 88 Max: 4918 Err: 752 (76.35%) Active: 30 Started: 30 Finished: 0
summary = 12859 in 00:05:25 = 39.6/s Avg: 616 Min: 88 Max: 6149 Err: 10562 (82.14%)
summary + 984 in 00:00:30 = 32.8/s Avg: 675 Min: 113 Max: 5070 Err: 762 (77.44%) Active: 30 Started: 30 Finished: 0
summary = 11874 in 00:04:55 = 40.3/s Avg: 614 Min: 100 Max: 6149 Err: 9810 (82.62%)
summary + 1103 in 00:00:30 = 36.7/s Avg: 624 Min: 104 Max: 4935 Err: 884 (80.15%) Active: 30 Started: 30 Finished: 0
summary = 10890 in 00:04:25 = 41.2/s Avg: 609 Min: 100 Max: 6149 Err: 9048 (83.09%)
summary + 1220 in 00:00:30 = 40.6/s Avg: 584 Min: 100 Max: 6149 Err: 1001 (82.05%) Active: 30 Started: 30 Finished: 0
summary = 9787 in 00:03:55 = 41.7/s Avg: 607 Min: 100 Max: 6149 Err: 8164 (83.42%)
summary + 1336 in 00:00:30 = 44.5/s Avg: 570 Min: 106 Max: 5296 Err: 1106 (82.78%) Active: 30 Started: 30 Finished: 0
summary = 8567 in 00:03:25 = 41.9/s Avg: 610 Min: 106 Max: 5643 Err: 7163 (83.61%)
summary + 1320 in 00:00:30 = 44.0/s Avg: 587 Min: 116 Max: 5187 Err: 1111 (84.17%) Active: 30 Started: 30 Finished: 0
summary = 7231 in 00:02:55 = 41.4/s Avg: 618 Min: 106 Max: 5643 Err: 6057 (83.76%)
summary + 1273 in 00:00:30 = 42.5/s Avg: 637 Min: 106 Max: 5383 Err: 1072 (84.21%) Active: 30 Started: 30 Finished: 0
summary = 5911 in 00:02:25 = 40.9/s Avg: 625 Min: 106 Max: 5643 Err: 4946 (83.67%)
summary + 1430 in 00:00:30 = 47.6/s Avg: 591 Min: 116 Max: 5643 Err: 1229 (85.94%) Active: 30 Started: 30 Finished: 0
summary = 4638 in 00:01:55 = 40.5/s Avg: 621 Min: 106 Max: 5643 Err: 3874 (83.53%)
summary + 1467 in 00:00:30 = 48.9/s Avg: 589 Min: 119 Max: 4691 Err: 1267 (86.37%) Active: 30 Started: 30 Finished: 0
summary = 3208 in 00:01:25 = 37.9/s Avg: 635 Min: 106 Max: 4691 Err: 2645 (82.45%)
summary + 1070 in 00:00:30 = 35.7/s Avg: 651 Min: 99 Max: 7324 Err: 862 (80.56%) Active: 30 Started: 30 Finished: 0
summary = 13929 in 00:05:55 = 39.3/s Avg: 619 Min: 88 Max: 7324 Err: 11424 (82.02%)
summary + 1531 in 00:00:30 = 51.1/s Avg: 594 Min: 106 Max: 5194 Err: 1332 (87.00%) Active: 30 Started: 30 Finished: 0
summary = 15460 in 00:06:25 = 40.2/s Avg: 617 Min: 88 Max: 7324 Err: 12756 (82.51%)
I'm not sure if you understand the difference between Threads and requests. amount of Threads isn't equal to requests, what you're seeing in the output is the amount of requests made by your threads, and depending on your response times it's very well possible to get that many results.
Try setting the Loop count to 1 or 2 and you'll see that the requests will even out with your calculations.
Beside that... in your output on the far right side you can see how many Threads are started.
With your current setup, threads will start with one second delay.
Ramp up period is the time in which all treads should start.
You have loop set to infinite, so when all thread login after initial 30 seconds, you will always have 30 active users, and could never have more that that.
You have many more requests, depending on response time of your server, but threads are like users. If you set 30, it will always be 30. :-)
You are running 30 virtual users for 10 minutes. Each virtual user is executing samplers as fast as it can (the speed mostly depends on your application response time) this is why you have a lot of requests.
If you need to limit JMeter throughput to 60 requests per second only you can do it using Constant Throughput Timer:
Add Constant Throughput Timer to your Test Plan
Set "Target Troughput" to 60
Set "Calculate Troughput based on" to All active threads
This way JMeter will "pause" its threads (virtual users) to slow them down to 60 requests per minute.

Summary is not getting update sometimes while executing Jmeter Script in Non GUI Mode

Sometimes the summary didn't get update while executing JMeter script in Non GUI Mode, Please find below data.
Starting the test # Wed Jan 04 18:41:18 IST 2017 (1483535478893)
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary + 28 in 00:00:11 = 2.5/s Avg: 3376 Min: 1991 Max: 7555 Err: 0 (0.00%) Active: 37 Started: 37 Finished: 0
summary + 192 in 00:00:30 = 6.4/s Avg: 5623 Min: 812 Max: 19523 Err: 0 (0.00%) Active: 137 Started: 137 Finished: 0
summary = 220 in 00:00:41 = 5.4/s Avg: 5337 Min: 812 Max: 19523 Err: 0 (0.00%)
summary + 196 in 00:00:30 = 6.6/s Avg: 9388 Min: 813 Max: 46485 Err: 1 (0.51%) Active: 200 Started: 200 Finished: 0
summary = 416 in 00:01:11 = 5.9/s Avg: 7246 Min: 812 Max: 46485 Err: 1 (0.24%)
summary + 159 in 00:00:31 = 5.2/s Avg: 11175 Min: 796 Max: 79142 Err: 0 (0.00%) Active: 200 Started: 200 Finished: 0
summary = 575 in 00:01:42 = 5.6/s Avg: 8332 Min: 796 Max: 79142 Err: 1 (0.17%)
summary + 50 in 00:00:29 = 1.7/s Avg: 39434 Min: 820 Max: 108309 Err: 1 (2.00%) Active: 200 Started: 200 Finished: 0
summary = 625 in 00:02:11 = 4.8/s Avg: 10820 Min: 796 Max: 108309 Err: 2 (0.32%)
summary + 104 in 00:00:30 = 3.5/s Avg: 44422 Min: 846 Max: 125336 Err: 0 (0.00%) Active: 196 Started: 200 Finished: 4
summary = 729 in 00:02:41 = 4.5/s Avg: 15614 Min: 796 Max: 125336 Err: 2 (0.27%)
summary + 189 in 00:00:30 = 6.3/s Avg: 37163 Min: 5912 Max: 168988 Err: 0 (0.00%) Active: 172 Started: 200 Finished: 28
summary = 918 in 00:03:11 = 4.8/s Avg: 20051 Min: 796 Max: 168988 Err: 2 (0.22%)
summary + 208 in 00:00:30 = 6.9/s Avg: 27117 Min: 5369 Max: 180636 Err: 0 (0.00%) Active: 132 Started: 200 Finished: 68
summary = 1126 in 00:03:41 = 5.1/s Avg: 21356 Min: 796 Max: 180636 Err: 2 (0.18%)
summary + 232 in 00:00:30 = 7.7/s Avg: 34571 Min: 4706 Max: 220724 Err: 0 (0.00%) Active: 65 Started: 200 Finished: 135
summary = 1358 in 00:04:11 = 5.4/s Avg: 23614 Min: 796 Max: 220724 Err: 2 (0.15%)
summary + 171 in 00:00:30 = 5.7/s Avg: 21823 Min: 4524 Max: 220385 Err: 0 (0.00%) Active: 22 Started: 200 Finished: 178
summary = 1529 in 00:04:41 = 5.4/s Avg: 23413 Min: 796 Max: 220724 Err: 2 (0.13%)
The output is not shown after the last line, I wait up to 45 Min but logs are not getting updated.
Few hints:
Check jmeter.log file for anything suspicious
Get thread dump using jstack or pressing Win + Break (on Windows) and check threads statuses, see if there are any deadlocked or looping processes
Use VisualVM to attach to the process and inspect heap, see garbage collections, etc.
Check if anything is being added to .jtl results file
Most probably your JMeter instance isn't properly configured in terms of Java Heap size, Garbage Collection mode or your test plan has some issues.
References:
Troubleshooting Hanging or Looping Processes
9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure

Resources