In JMeter when I right click Thread/Controller I have an option: Add Think Time to children feature , when I click on it I get after every Sampler Test Action Pause with Uniform Random Timer with Random Delay 100 and Constant Delay 1000.
I didn't find in documentation any reference to it and why/how it should be used.
Is it configurable and how? is there a special case for it or should it be used for loading best practice ?
Also you can add several times think times I'm not sure is it on purpose (add more delays after request)
EDIT
Configurable using jmeter.properties:
# Default implementation that create the Timer structure to add to Test Plan
# Implementation of interface org.apache.jmeter.gui.action.thinktime.ThinkTimeCreator
#think_time_creator.impl=org.apache.jmeter.thinktime.DefaultThinkTimeCreator
# Default Timer GUI class added to Test Plan by DefaultThinkTimeCreator
#think_time_creator.default_timer_implementation=org.apache.jmeter.timers.gui.UniformRandomTimerGui
# Default constant pause of Timer
#think_time_creator.default_constant_pause=1000
# Default range pause of Timer
#think_time_creator.default_range=100
When it comes to web applications load testing the idea is to represent a real user sitting in front of computer using a real browser as close as possible.
Well-behaved JMeter test needs to mimic this real user with all its stuff like:
headers
cookies
cache
embedded resources
AJAX requests
etc.
The purpose of using Timers in JMeter tests is simulating real users "think times". Users don't hammer application non-stop, they need some time to "think" between operations, fill forms, type comments, even clicking on a button or link takes some time. So if you are testing if your web application supports X users each JMeter thread must act like a real user so you need to add reasonable think times using Timers. There is no "best practice" or "known good values", it depends only on your web application specifics. See A Comprehensive Guide to Using JMeter Timers for more details.
This feature is made to simplify addition of Think Times, the way it adds them to plan lead to pause between every sampler while if you just add a Timer it will be scoped and thus be applied before all samplers in scope.
As it's a helper, it adds default Pause of 1 second that are configurable by tuning the properties you have mentioned and which are documented :-) :
http://jmeter.apache.org/usermanual/properties_reference.html#timer
You can adjust:
The type of Timers you want to create
The constant and variable pause range
You can even create your own class that would work differently.
Related
I have a few question to clarify on my understanding of how JMeter works.
a. Thread Group determine the number of users but it does not determine how many HTML requests are generated per sec ? By default, I notice that every user will send a HTML request at a rate of 2 RPS.
b. If I want to change the RPS per user, then I need to use the Through Put Timer. But the Timer can only lower the request rate from 2 RPS to a lower number. It does not increase the RPS.
c. In order to increase the RPS, I need to add more Threads.
d. Does this mean we are limited to 2 RPS per user ? I see some website have links to many other websites so a webpage refresh would make many requests.
Is this the way JMeter works ?
I have a load test which has 8 transaction (eg CRUD,...). I intend to create a overall Test Plan and I want to use INCLUDE to add all the 8 txn. Do I just record the website and INCLUDE ? What should I include, only the HTML requests ?
I'm also thinking of adding Think Time and Add Variables in the 8 scripts before I INCLUDE.
Do I add the Config Element (eg CSV Dataset Config) in the 8 scripts or the overall Test Plan ?
Thanks.
By default each JMeter thread (virtual user) executes requests as fast as it can. If you want to slow JMeter down to mimic a real user which doesn't hammer the server non-stop and needs some time to "think" between operations - use Timers. More information: How do I Correlate the Number of (Concurrent) Users with Hits Per Second
If you want more RPS - add more threads (assuming that the system under test can give you more RPS)
You should INCLUDE everything which is related to your website (images, scripts, styles, fonts, sounds, etc.) but in the same manner as your browser does, i.e. don't record these requests and instead configure JMeter to download embedded resources and use HTTP Cache Manager so JMeter would request these resources just like browser does. Any requests to "external" websites should be excluded (unless they're also developed and supported and in scope for testing)
That's a good approach, if you use a value more than once it makes sense to declare it via User Defined Variables so you would be able to amend the value only in one place
You add it according to your scenarios, be informed about JMeter Scoping Rules
I had recorded the script using blaze meter plugin, and using ultimate thread group, I am not able to figure out:
Why there is delay in sending first request? I have not set any delayed and start-time is also for 1 second
Also in my result tree I am seeing multiple http requests called. What am I doing wrong here?
We are not telepathic enough to guess why do you have the "delay" without seeing your test plan, most probably there is something like "Think-Time" or other Timer there
having non-zero "Thread Delay" value. This is to simulate real user using the real browser. Real users don't hammer the application under test non-stop, they need some time to "think" between operations so most probably this delay is due to the timer action
If you look at Defaults configuration element at the "Advanced" tab there is a setting instructing JMeter to download so-called "Embedded Resources". In the main HTML response there are multiple referenced elements like images, scripts, styles, fonts, sounds, etc. and JMeter parses the main HTML response, extracts these resources from there and downloads them as this is what real browsers do.
I have read the user guide, here or on Blazemeter blogs regarding usage of flow action to implement dynamic pacing in Jmeter script with help of a JSR223 timer. I wanted to check if I can use JMX dummy sampler to implement the same JSR223 timer?
Does it really impact performance if using Dummy Sampler vs Flow Action in performance test scripts as both are samplers only. Please advise and any support link would be appreciated.
Impact performance of what?
"Pacing" is yet another approach to control the number of hits per second by slowing down the requests for whatever reason (not to overwhelm the application, send desired number of requests per second, etc.)
Any implementation of "pacing" is "killer" of the performance because it adds a pause between iterations instead of starting new iteration immediately so your question doesn't make a lot of sense. If you want to use the most resource efficient solution - you need to either share your implementation details for these 3 approaches or better measure it yourself using a profiler tool
If you're looking for a easier/better way of sending requests at constant rate instead of implementing the "pacing" I would rather recommend considering using of the following test elements:
Constant Throughput Timer
Precise Throughput Timer
Throughput Shaping Timer
I have a web test where my requirements need a handful of different polling requests to be going on in the background. I have created a WebTestPlugin that looks for a certain context parameter to be set, and once it is, it kicks off a thread that just loops (every X seconds) firing off the configured request.
My issue is that this is not done in the context of the test, therefore the results (# of calls, duration, etc) is not part of the final report.
Is there a way to insert this data?
Rather than starting your own thread to run the background requests I suggest using the facilities of the load test. That way the results will be properly recorded. Another reason is that the threading regime of a load test is not specified by Microsoft and adding your own thread may cause issues.
You could have one scenario for the main test. Another scenario has one or more simple tests for the background polling activity. These tests could be set with a "think time between iterations" or with "test mix based on user pace" to achieve the required background rate. To get the background web tests starting at the correct time start the test with a constant load of 0 (zero) users and use a load test plugin that adjusts the number of users whenever needed. The plugin writes the required number into m_loadTest.Scenarios[N].CurrentLoad for a suitable N. This would probably be done in the Heartbeat plugin but potentially could be in any load test plugin. If may be that the TestFinished plugin can better detect when the number of users should increase.
I have recorded my web application through template & just to confirm that load test result which i am getting is correct? Just by increasing No of users does it give proper results? Is it enough for load testing of web application?
First of all you need to ensure that your test does what it is supposed to be doing. Recorded tests can rarely be successfully replayed, so normally you should be acting as follows:
Add View Results Tree listener and run your test with 1 user. Inspect request and response details to verify your test steps.
Perform correlation and parametrization if required.
Correlation: the process of identifying and handling any dynamic parameters. Most often people use Regular Expression Extractor for it.
Parametrization: the process of making your test data driven. For example, if your application assumes multiple authenticated users you need to store the credentials somewhere. Most commonly used test element for this is CSV Data Set Config
Make your test realistic. Virtual users simulated by JMeter need to represent real users using real browsers as close as possible with all the related stuff: cookies, headers, cache, etc. See How To Make JMeter Behave More Like A Real Browser to learn how to configure JMeter to act closer to real users. Also real users need some time to "think" between operations so make sure you are using Timers to simulate this behaviour as well.
Only after you apply the above points you should add more virtual users. Again, run your test with 2-3 users and iterations to ensure your test funcitons as designed. Once you are happy with it you can increase the load, but don't overkill your server, increase the load gradually and check the impact of the increasing load on your application, i.e. how response time, throughput and number of errors change as you increase the load. The same is applicable for decreasing the load, don't turn it off at once, decrease the number of virtual users gradually.
Building a Web Test Plan
Building an Advanced Web Test Plan