In JMeter the main goal of using timers is simulating a virtual user’s “think time”. Is this possible to run a test that can dynamically change think-time at user's will in order to test a particular behavior of multi-threaded application. For example if i define Poisson Random Timer for my test and at the run time I want to load the server with burst of request with heavy-tailed distribution and for this purpose i want to switch from Poisson to Guassian distribution(e.g.) then what i have to do during preparing a Test Plan or what I can do during test is running?
You cannot change timers implementation, but in terms of constant delays and offsets - this is something you can change in the runtime.
Define "think times" using JMeter properties having some reasonable default values via __P() function like ${__P(think-time,5)}
When your test is running you can control think-time property value via Beanshell Server increasing or decreasing it according to your test scenario.
See A Comprehensive Guide to Using JMeter Timers article for more detailed explanation on using timers in JMeter tests.
Related
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 performance test in JMeter and would like to test maximum system performance/throughput with it. So number of active threads should be increased for example while Error rate is under 2 %. I found Constant Throughput Timer, put it into Thread Group but it only pause or slow down threads. I tried define it as follows, with a property: ${__P(throughput,)}, but not sure what should be correct value for this property. I can't see how JMeter could measure system maximal performance.
There is no Out of the box solution as of JMeter 3.3, see this enhancement request:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57640
Still it is possible to dynamically add threads since JMeter 3.2 (see https://bz.apache.org/bugzilla/show_bug.cgi?id=60530) in a JSR223 Test Element using JMeterContext:
ctx.getThreadGroup().addNewThread(delay, ctx.getEngine());
So based on this, you could in a JSR223 Test Element (Pre/Post Processor or Sampler) check the presence of a file in a folder of your choice named :
NUMBER_OF_THREAD_TO_ADD.txt
If present, use its name to compute number of threads and call this method.
There is no such functionality in the "vanilla" JMeter howere it is possible with plugins, check out:
Concurrency Thread Group
Throughput Shaping Timer
They can be connected together via feedback loop so Concurrency Thread Group will add more threads if needed to reach the desired number of requests per second.
You can install both the plugins (and keep them up-to-date) using JMeter Plugins Manager
We're running a test case for load testing, over different servers. What we want to do is, given that test case, stop if we can see a performance decrease, based on a response time threshold.
What we have now is threadgroup defined, and inside it, an HTTP request defined plus a view table for output. What should I do to put this control in there?
Add Duration Assertion and specify threshold there
In your Thread Group set "Action to be taken after a Sampler error" to Stop Test.
Above steps will stop your test after first occurrence of response time exceeding the threshold.
See How to Use JMeter Assertions in Three Easy Steps article for more information on how to conditionally set pass/fail criteria in your JMeter test.
P.S.
Remove View Results Table listener (or disable it) during load test execution as it consumes a lot of resources.
Run your load test in non-GUI mode as JMeter GUI is not designed for running the actual load test and may be a bottleneck in case of more or less severe load.
I've a simple scenario written in JMeter. Now I want to use SmartMeter instead of JMeter, but I don't know if I have to create a new scenario/test or if can reuse the old one?
I speak about http://www.smartmeter.io/
In an environment of SmartMeter Editor we can run the Test 1:1, then it is virtually identical run as in JMeter 2.12 and it does not use distributed mode. But we can watch the test in the Runner tab and after the test to generate the report (if the listener "et#sm - Controller Summary Report" is included the test).
For a distributed mode we recommend using SmartMeter Thread Group "et#sm - Distributed Lazy Stepping Thread Group", which creates users at the moment of their involvement in a testing process and they are also automatically distributed to generator servers with exact deviation between them and keeping the number of VU from the settings.
You also need to add a component of listener "et#sm - Controller Summary Report" to store the results and display informations in SmartMeter runner.
Further adjustments are voluntary, but I can only recommend them:
To use assert "et#sm - Better Response Assertion" which works much more efficiently and faster ; To retrieve values from the response exploit "et#sm - Boundary Points Extractor" etc.
Is it possible to automate the load tests in Jmeter and increase the number of threads until the first error is observed?
For example I start with testing 16 threads for every seconds and increase the number until i receive an error. But instead of doing this manually can I let this run automatically?
Looking into Pre-defined Properties section of JMeter's User Manual on Functions there is a JMeterThread.last_sample_ok variable holding result of the last sampler execution.
So if you build your test plan as follows:
Sampler which does test action
If Controller checking whether previous sampler was successful
If not - relevant actions (stop test, send email, stop ramping up virtual users, etc.)
The value you need to put in "Condition" input of If Controller should look like
"${JMeterThread.last_sample_ok}"=="false"
See How to use JMeter's 'IF' Controller and get Pie for more information on JMeter's If Controller.
Regarding threads in jmeter You may find those 2 links interesting:
What is the highest number of threads that is reasonable to simultaneously run in Jmeter?
JMeter max. thread limit
Regarding your methodology, why not use slow rampup and see the limit using what Dmitri T has provided ?