I am trying to extract a value from one HTTP responseand add it in another HTTP Request name. It works, but when I run many threads, for example, 100 or more, the regex value is not displayed in the HTTP Request name. Instead it displays the default value. If the thread number is 100, then 10-15 are with the default value. what could be the reason?
It means that the server does not support 100 users load as it sending some other response (may by 5** HTTP response codes). save the results in .csv/.jtl file and check whether these error codes are observed.
If your script is working for a few users, but not working when load is increased, then it is the fault at server side where its resources might have touched the bottlenecks.
I suggest the following steps to try:
Increase the Heap space for JMeter (which is a Java application). default value is 512MB. increase the value in jmeter.bat.
set HEAP=-Xms1024m -Xmx2048m
Run the JMeter in non-GUI mode to save the resources.
while running the load testing using non-gui mode, specify -l results.jtl to save the results. once the test is completed, check for status codes under responseCode column.
Related
I want to know how many HTTP requests per second my server can handle using Jmeter.
I got throughput 128/mins which means 2/3 req per sec. but something is wrong in my sampler can you tell what I need to do to test the login URL?
Hammering a login page doesn't have anything in common with the load testing as load testing is checking your application against the anticipated load.
If you're trying to determine the maximum number of requests per second your server can handle - this is some form of stress testing
In both cases you should come up with a realistic test scenario which would represent real users using real browsers like:
Record your scenario using JMeter's HTTP(S) Test Script Recorder
Perform parameterization and correlation
Run your test with several virtual users/iterations and inspect request/response details using View Results Tree listener to ensure that your test is doing what it is supposed to be doing
Once you're happy with your test script - disable the View Results Tree listener and run full load test using command-line non-GUI mode
Analyze your results using JMeter Reporting Dashboard
With regards to your goal I would recommend increasing the load gradually so you would be able to correlate the increasing number of users with the increasing throughput.
When you reach the point where you're adding more users and the throughput doesn't increase - it means that the application cannot handle more load hence that would be the maximum number of users/requests per second your application can handle.
Update - Deleting the Aggregate report and rerunning the test now gives an error rate of 0. Why is this required?
I am using JMeter 4.0 to hit a REST web service with 20 thread groups by sending a POST request with a JSON body. All 20 requests succeed and give proper response (200 with a correct JSON body). Why is the error rate above 99%? (See image below). Also, why is no of samples is 10063 in report even though View Results Tree tab shows 20 HTTP requests (each with error count 0).
If you run JMeter test which assumes 20 HTTP Request and seeing > 10 000 in the listener - most probably you are opening an incorrect .jtl results file in the listener.
Double check that "Filename" input field is empty
Prior to running a new test make sure to clean "in-memory" results by choosing Run -> Clear All from JMeter's main menu (or click Control+E)
Be aware that using Listeners is a some form of a performance anti-pattern, they don't add any value but consume valuable system resources which can be either used for something else or left intact to save the trees. So:
Remove all the listeners from the test plan
Run your test in command-line non-GUI mode like:
jmeter -n -t test.jmx -l result.jtl
When your test is finished either open JMeter GUI and inspect the result.jtl file with the listener of your choice (you can load it using aforementioned "Filename" tab)
Or generate an HTML Reporting Dashboard out of the result.jtl file - it will contain statistical information, tables and charts outlining your test results.
View Results Tree since few versions only keep last 500 SampleResult and only refreshes every few seconds.
So the number of samples in view results tree is not the total.
Besides, you should never run a load test in GUI mode as it impacts negatively performances of Jmeter injection.
see this for best practices :
https://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
I record and run the Jmeter script by keeping number of users = 1, in tread group.
Results tree output:
I increased the number of users to 3 and result tree output order changed.
Therefore my some of regular expression exacter logics get failed and resultant responses failed. How can I avoid this situation.
Is there way to manage result tree execution order.
If your regular expressions are under the requests and not at the same level as of HTTP requests then it should not be a problem.Every thread/vUser will run independently. But, in view results you will see request as and when executed by different threads and not in sequence.
As per JMeter Functions and Variables user manual chapter:
Variables are local to a thread
Each JMeter thread (virtual user) executes Samplers upside down (or according to the Logic Controllers). JMeter threads are absolutely independent from each other and each thread has its own variables.
So the problem must be somewhere else, inspect the state of the variables using Debug Sampler and the response data for /oauth calls - it might simply not contain the necessary token value.
Also there is a suspicious call to bundle.js, my expectation is that you should not be executing it directly. The good practices is to configure HTTP Request Defaults to download embedded resources and use parallel pool to be closer to what real browsers do.
See Web Testing with JMeter: How To Properly Handle Embedded Resources in HTML Responses article for more detailed explanation.
I need some possibility to conduct load testing of our REST API with traffic counting.
For example to run 20 concurrent user for 1 hour. As a result I want to get information about responses (avg time, delays, etc) and overall traffic that has been produced.
I overlooked JMeter and Gatling, but found no possibilities to count bytes.
I don't really need big amount of concurrent users (100 would be enough) and high throughput (more than 10 requests per second from single user).
My goal is just to produce some load on our system and to check that it shows correct statistic data.
JMeter (checked with latest 3.3) already save sent/received bytes by default, you can see in Listener's Configure button:
Save sent bytes count
Save received bytes count
You will get in jtl file saved columns ..,bytes,sentBytes..
By default JMeter should be saving sent and received bytes in .jtl results file
If it doesn't - add the next lines to user.properties file (lives in "bin" folder of your JMeter installation)
jmeter.save.saveservice.bytes=true
jmeter.save.saveservice.sent_bytes=true
Also make sure you have HttpClient4 implementation selected on the "Advanced" tab of HTTP Request sampler (or HTTP Request Defaults)
In my test I run a script sampler(BSF Sampler) that uses the result of the HTTP Request Sampler before it.
The problem is that when I run the test, distributed, in mode=StrippedBatch (the default mode) the script sampler fails.
Here's a striped down wersion of my script: (the result is 0)
bytes = prev.getResponseData();
OUT.println(bytes.length);
I have tryed the test localy and also distributed in mode=Standard and it works fine (the problem is not present).
Does this mean that slave can't access the result of the samplers, if the data is not send to the master? Isn't that a big hit on the performance?
StrippedBatch mode does this:
result.setBytes(result.getBytes());
result.setResponseData(new byte[0]);
Which is why you get your "strange" results.
Your option would be to do it in Post Processor and save your var in Thread Variables.
But it is not a good thing to save the full response as it can consume a lot of memory.