I calculate some statistics (e.g. average request duration) while my tests are running using code similar to this:
https://stackoverflow.com/a/27446405/2173353
However, I want to know when the test is done running (all the samplers have executed), so that I act upon the statistics then, and not before that. Essentially, I want to assert on the average duration of the requests when all requests are done.
Is there a way to execute code when the test is about to finish?
You must probably be looking for the tearDown Thread Group. It is some form of "special" thread group, the difference from "normal" Thread Groups is that the tearDown Thread Group is being executed after all other Thread Groups therefore you will be able to perform your "near the end" actions there.
More information: How to Use the SetUp Thread Group in JMeter When Preparing a Load Test
Related
I need to run a load test of 25 threads, what will be the most efficient configuration to use? (ramp-up period....). I ran the load test with the below configuration and some of the threads failed but pass if I just ran the script individually.
Your configuration will mean that:
JMeter start with 1 thread and add another thread each 4 seconds
Once started each thread will begin to execute Samplers upside down (or according to the logic controllers)
When the thread executes the last sampler it will be shut down
When the last thread executes the last sampler the test ends
Depending on the number of samplers and application response time you may or may not achieve 25 users concurrency, you might want to check the actual number of concurrent users using Active Threads Over Time listener
If you want to make sure to have 25 online users set "Loop Count" to Infinite and "Specify Thread Lifetime" duration to be more than your ramp-up period. See JMeter Test Results: Why the Actual Users Number is Lower than Expected article for more details.
With regards to the failures - we cannot state anything meaningful without seeing request and response details, make sure to save them using i.e. View Results Tree listener and inspect response body for the failed requests
i am running a simple test with 10 users for 5 mins. my test has a single thread and different transactions within it. By the end of the test, there is a different number of samples for each transaction. Is there a way or a setting so that we don't start any new thread when the test is finishing, i tried ultimate thread group plugin with ramp down , hoping to see same samples for all requests but it didn't happen. Not sure if that is even possible.
Each JMeter thread (virtual user) executes Samplers upside down (or according to the Logic Controllers)
When you're defining test duration it might be the case that some virtual users are somewhere in the "middle" of the Samplers and they stop when they receive shutdown signal.
It means that the very first sampler will be executed with 100% of users and for further samplers the chance of getting executed becomes lower and lower.
The only way to have the same number of Sample Results for all Samplers is using normal JMeter Thread Group and providing fixed amount of loops.
Given above setup you will have strictly 80 executions of each and every Sampler in the Test Plan
More information: Getting Started with JMeter - A Basic Tutorial
I am new to JMeter. I'm using JMeter version 5.0.
I have created a new Test Plan. Test Plan has a few settings.
Can you please explain the use of each checkbox?
Checkboxes are:
1) Run ThreadGroups consecutively(i.e one at a time)
2) Run tearDown ThreadGroups after shutdown of main threads.
3) Functional test mode(i.e. save Response data and Sampler Data)
When trying to understand JMeter, go through its component reference (below)
You should keep the defaults unless specific case is needed.
Functional Testing is not recommended/needed unless you are debugging (and also not needed usually)
teardown/setup groups are useful for setting/cleaning tasks in test.
And usually you want run multiple Thread Groups serially rather than in parallel.
Selecting Functional Testing instructs JMeter to save the additional sample information - Response Data and Sampler Data - to all result files. This increases the resources needed to run a test, and may adversely impact JMeter performance. If more data is required for a particular sampler only, then add a Listener to it, and configure the fields as required.
The option does not affect CSV result files, which cannot currently store such information.
Also, an option exists here to instruct JMeter to run the Thread Group serially rather than in parallel.
Run tearDown Thread Groups after shutdown of main threads: if selected, the tearDown groups (if any) will be run after graceful shutdown of the main threads. The tearDown threads won't be run if the test is forcibly stopped.
1) Run ThreadGroups consecutively(i.e one at a time)
In a test plan usually, you would have different thread groups ( user groups ) sending requests to different services. For example
Thread Group 1 > Load and Login to the System
Thread Group 2 > A Form Submission in the System
Keeping the above-mentioned thread groups, if you have selected Run ThreadGroups consecutively option it will run The Thread group 1 first and then move to the second one. If not there will be a parallel execution of all active Thread groups.
2) Run tearDown ThreadGroups after shutdown of main threads
There is no difference in a normal Thread Group and a Teardown Thread Group when it comes to the functionality. You can specify the Post-Test actions in the Teardown Thread Group and use Run tearDown ThreadGroups after shutdown of main threads to execute them after the normal thread Group Execution
As an example if you have created a user profile for your performance testing purposes and if you want to remove the user after the test execution. You can create the request to delete the user in this thread group
3) Functional test mode(i.e. save Response data and Sampler Data)
When you run a huge set of requests I recommend you to NOT to use this. The reason is if you have selected this option it will include all the request and response data (including HTML, etc. ) in your log files. ( Normally it won't record your response and sampler data ) Even if you run the test in NON-GUI mode the log file would be few GBs if you have selected this option. So it's better to use this if you are debugging or running a less number of users in your test.
Run ThreadGroups consecutively(i.e one at a time)
If your test plan contains two thread groups i.e ThreadGroup-1 and ThreadGroup-2.
If above property is unchecked -then the active threads from both the thread group
will run parallel and
if checked - That means JMeter will start ThreadGroup-1 first, then ThreadGroup-2 and so on.
So by using this property you can instruct JMeter to run the Thread Groups serially.
Run tearDown ThreadGroups after shutdown of main threads
By default JMeter always run tear down thread group after completion of normal thread group. But if there is any failure in the above thread group and threads stopped due to some reason. Then this tear down thread group will not run. But if this property is checked then tear down thread group will always run.
Lets say we have 2 thread groups, one has 10 threads, another one has 30 threads. I have unchecked "run thread group consecutively". In table results, we see response time of second thread group is more than first threadgroup users.
When threadgroups are arranged other way, it shows reverse. So, whichever is second thread group, its user showing response time more than what is there in first thread group.
When you unchecked the "run thread group consecutively", then both the thread group runs in parallel. Now, based on the number of thread they will send the requests. In your scenario, 2nd thread group has created 30 threads and start sending the request. Now, based on,after how much time the response will come, it is listed in the view result. So, you thread group have more thread and may be getting response faster then thread 1. But, thread 1 is also going to be listed in the view results as shown below;-
Option is unchecked, so parallel running:-
So,in short, if "run thread group consecutively" option is unchecked, thread groups will run in parallel else sequential.
Option is checked, so sequential running:-
Hope this helps.
Only one explanation comes to my mind:
You're running your test in GUI mode
You're running it in GUI mode with Listeners enabled
If above assumptions are correct JMeter is simply lacking resources in order to kick off that many threads and given JMeter is not capable of sending requests fast enough you're getting "false negative" results as JMeter spends time in GC trying to free up some Heap space in order to be able to operate.
So:
Make sure to run your test in command-line non-GUI mode
Disable all the Listeners, they don't add any value, only consume valuable resources
Follow recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure in order to configure JMeter for maximum performance
Building a test plan in JMeter. I have different Transactions and each of them has number of HTTP samplers and "if conditions".
So basically each user might not perform the same action based on the "if condition". I want all the users to start performing the same transaction at the same time and also wait for the other users(Threads) if they have not reached to the current transaction.
I know that I can achieve this with the help of Synchronizing timer but somehow I am not able to achieve this with it.
How to achieve it with any possible method ?
PS - I just want the threads to start transaction at the same time. it does not matter if they performing same sampler or not.
I can suggest another approach,
You can use tearDown Thread Group,
execute after the test has finished executing its regular Thread Groups.
After all threads are done you execute tearDown and can execute anything you want, including Module Control which can reuse transaction from your main thread group
It is quite hard to guess what's going wrong without seeing your Test Plan structure. Just in case be aware that Timers obey Scoping Rules so if you want a request to be executed by N threads in parallel - you need to put the Synchronizing Timer as a child of this request.
See Using the JMeter Synchronizing Timer article for comprehensive information and example test plan.