I am using Apache JMeter 2.13 on Windows 7 and Java 1.8.0_73
I have a JMeter file set up with a thread group with 1 thread, 0 ramp-up period and 5 loop count. I've recorded the log in process for a web application using the recording controller, the HTTP(S) test script recorder and Firefox. I have added the other elements you can see in the screenshot below
I've then parameterized several of the requests to extract login tokens and moved the root URLs out into user variables (so that I can run it against my local build or any of the server builds) including a beanshell script for dynamic authentication headers in some of the requests.
When I clear results and then run the test script I see that the first request in the first iteration has a sample time of around 10 seconds, the same is true of the 4th request (the next major page).
The second iteration these same request takes ~600ms, the third iteration 350
e.g.
10318, 605, 350, 641, 310
I then clear results, run again with 10 loops
10366, 1012, 600, 300, 293, 632, 324,292, 331, 291
So my questions are: Is this expected JMeter behaviour?
Is there anyway to change it
Usually you have to have some warmup method to be run first. Just to set up all the stuff, to reach the db, start some threads, etc.
The results of the warmup are not taken into account when analysing the performance.
Related
We recently updated apache jmeter from v4.0 to the latest v5.4.3.
The tests are running fine, but we have strange results.
The requests appear with 3 different labels (without suffix or -0 / -1 appended).
timeStamp, label, responseCode, threadName
1643834640785, API call, 200, Load Group 1 1-1
1643834640785, API call-0, 302, Load Group 1 1-1
1643834641189, API call-1, 200, Load Group 1 1-1
1643834640785, API call, 200, Load Group 1 1-2
....
It seems to me this happens, when the same thread calls the API multiple times.
I am not a jmeter and I am not sure why this happens and how to fix it. Also I don't know what information is needed to analyze the problem correctly.
Thanks in advance!
I'm seeing HTTP Status 302 which means redirection (for example from HTTP to HTTPS or from global website to country-specific website), in that case JMeter generates additional Sub-Result.
The "strange" labels is how JMeter calculates throughput for embedded resources and the cumulative execution time of the parent sampler in case of redirects as well.
The question is what do you want to do with this.
The options are in:
Take it for granted given the above explanation
If you want the "strange" labels to be resolved into real URLs - tick "Functional Testing" box in the Test Plan
or add the next line to user.properties file:
subresults.disable_renaming=true
If you want to get rid of these subresults completely - add the next line to user.properties file:
jmeter.save.saveservice.subresults=false
More information:
Configuring JMeter
JMeter Properties Reference
i set up a 16-hour soak test in jmeter. use a csv file for different users for 10000 users. use ultimate thread group with these settings:
one row
start threads count: 20
initial delay: 0
start up time : 60 sec
hold for load : 57600 sec
shut down time : 10
i run the test 3 times. all of them ended in 8-9 hours.
on the server pc, i look for some settings of iis but didnt see anything.
the second day, in view result tree there was a response such that:
sampler result page
response message: non http response message: en established comnection was aborted by the software in your host machine.
does jmeter any limitation or iis have some timeout value?
JMeter doesn't have any internal "timeouts" for the test, it might be the case you test has.
For example I can think of 2 possible options:
Your CSV Data Set Config has either Recycle on EOF set to True or Stop thread on EOF set to False so when all 10000 lines are used the test stops
Your Ultimate Thread Group is configured to Stop Thread or Stop Test on the error and your test terminates when error occurs
The exact reason for stopping the test can be found in the jmeter.log file
I'm creating a small test using JMeter. So far I have one Thread Group that executes an HTTP request, waits for 10 seconds, then executes an other HTTP Request and checks what was returned. If I start 100 such threads with 1 second ramp-up period from the JMeter GUI, it works fine, I get the expected values and the whole test finishes in 22 seconds. However, when I start the very same jmx file from the command line, the test runs for more than 120 seconds and some threads (at the last run, 36 out of the 100) don't get the expected value. This might indicate a bug in the system I test, but I don't understand why the test takes that long time from the CLI and why I get errors from the CLI. What is the difference between running the test from the GUI and from the CLI? Does the CLI run the tests "more parallel"? By the way, this is the command line I'm using:
/home/nar/apache-jmeter-3.3/bin/jmeter -n -t test_transactions.jmx -l test_transactions.out
I'm afraid I cannot share the test plan, but I can share the "outline":
+ Thread Group
+ CSV Data Set Config
+ HTTP Request
| + JSON Extractor
+ Constant timer
+ HTTP Request
| + JSON Extractor
| + Response Assertion
+ View Results Tree
+ Save Responses to a file
+ View Results in Table
+ Summary Report
The Constant timer waits for 10 seconds. The first HTTP Request sends in some data and initiates a computation, the second checks the result.
I think you should disable the following listeners in non gui test:
View Results Tree
Save Responses to a file
View Results in Table
Summary Report
After disable you still have result using -l test_transactions.out which you can later view using GUI mode with Browse button in your Listener
In non GUI you can also generate dashboard report if you want by adding -e -o /path/dashboardfolder
It actually does indicate the bug in the system under test. The reason is that you must run JMeter in non-GUI mode as GUI creates huge overhead in terms of resources consumption, especially when you're using Listeners, especially if one of them is View Results Tree.
So my expectation is that in non-GUI mode you're basically creating more immense load which your application cannot handle. You can check this out using i.e. Active Threads Over Time and Transactions Per Second listeners.
I have the next test plan in JMeter:
on the screenshot you can see the settings for the 1st ThreadGroup, wich has 50% of common amout of request in test plan (in each Thread Group are 10 different subrequests placed).
So, +1 request per second is added in average using these settings.
Then I ran this test and saw this picture (Error % column):
I save errors in file and all these errors have the same text:
<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp#gc - Stepping Thread Group1 3-247" dt="text" by="0"/>
Server's cpu screenshot:
and for database:
After the errors have appeared my comp started work slowly and slowly (although the errors stopped to appear further)...
And in the same time the server's cpu progressively dropped to 0.
Could you tell me, please,
What is the reason of this error?
Have I reached the server timeout? (Because Max is more than 30s in the table).
UPD. I have rerun test with next settings: 1000 users per 02:46:40 (+1 Thread Group per 10 second and 10 requests inside each new Thread in the Loop).
I.e. I have reduced the time of test and total Thread Groups by 2 times, but save intensivity of Thead's adding.
The results are the same (including cpu usage on the server).
I've received the error «Connection reset» after 990 thread started. There are screenshots:
Any idea?
First, WebService(SOAP) Request is not the best way to test Webservices in JMeter, it will be deprecated in upcoming 2.9 version.
HTTP Sampler is the one to choose as it performs much better.
Second, Connection Reset means your server has cut connection. It could be coming from the CPU which seems high but it's not sure.
If what you call "my comp" is the computer hosting JMeter started working slowly then your JMeter instance is overwhelmed by the number of threads (2003 or more?) you've configured. It can come from a lot of factors, read this:
http://www.dzone.com/links/see_how_to_make_jmeter_run_thousands_of_threads_w.html
I have the next test plan in JMeter:
on the screenshot you can see the settings for the 1st ThreadGroup, wich has 50% of common amout of request in test plan (in each Thread Group are 10 different subrequests placed).
So, +1 request per second is added in average using these settings.
Then I ran this test and saw this picture (Error % column):
I save errors in file and all these errors have the same text:
<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp#gc - Stepping Thread Group1 3-247" dt="text" by="0"/>
Server's cpu screenshot:
and for database:
After the errors have appeared my comp started work slowly and slowly (although the errors stopped to appear further)...
And in the same time the server's cpu progressively dropped to 0.
Could you tell me, please,
What is the reason of this error?
Have I reached the server timeout? (Because Max is more than 30s in the table).
UPD. I have rerun test with next settings: 1000 users per 02:46:40 (+1 Thread Group per 10 second and 10 requests inside each new Thread in the Loop).
I.e. I have reduced the time of test and total Thread Groups by 2 times, but save intensivity of Thead's adding.
The results are the same (including cpu usage on the server).
I've received the error «Connection reset» after 990 thread started. There are screenshots:
Any idea?
First, WebService(SOAP) Request is not the best way to test Webservices in JMeter, it will be deprecated in upcoming 2.9 version.
HTTP Sampler is the one to choose as it performs much better.
Second, Connection Reset means your server has cut connection. It could be coming from the CPU which seems high but it's not sure.
If what you call "my comp" is the computer hosting JMeter started working slowly then your JMeter instance is overwhelmed by the number of threads (2003 or more?) you've configured. It can come from a lot of factors, read this:
http://www.dzone.com/links/see_how_to_make_jmeter_run_thousands_of_threads_w.html