JMeter override timers / reduce timer for certain step in larger scope - jmeter

I am running a JMeter scenario which has a certain think time applied for the entire scenario.
During one small loop in this scenario, I wish to decrease the think time between each sampler. E.g., if the default scenario think time, for all samplers, is 500ms, I wish to make this one small loop have a think time of only 100ms.
It does not seem like this is possible, but I also don't see any other questions asking this. Does anyone know of a workaround to accomplish what I am trying for?
This line in the JMeter docs suggests that this is not possible:
Note that timers are processed before each sampler in the scope in which they are found; if there are several timers in the same scope, all the timers will be processed before each sampler.
https://jmeter.apache.org/usermanual/component_reference.html#timers

You can do the following:
Declare a JMeter Variable to hold the default think time somewhere in User Defined Variables
In all Constant Timers (or in the one if it's applied to all the Samplers) set it to use the JMeter Variable from the step 1:
Before entering your "small loop" add a JSR223 PostProcessor to the last Sampler and put the following code into "Script" area:
vars.put('think-time', '100')
In the above code vars stands for JMeterVariables class instance, see Top 8 JMeter Java Classes You Should Be Using with Groovy article for more information if needed.
Before exiting the "small-loop" do the reverse thing and restore the original value of the think time

Related

How to run a JSR223 PreProcessor script once per loop

I currently have a loop that executes a bunch of queries via JDBC request samplers. They should all share a random ID that changes on every loop.
I tried using the beanshell script and JSR223 PreProcessor. But the PreProcessor gets executed before every single JDBC reuqest sampler, not once per loop. I feel like there is an obvious fix to my problem that I am missing.
I also tried putting the JSR223 script into an "Only Once Controller". But then the random variable I inject with vars.put() is not visible to the JDBC sampler. Also, as far as i understand the Only Once Controller, it would only execute on the first loop iteration. Which is not what I want.
JSR223 PreProcessor obeys JMeter Scoping Rules so if you put it to be a child of i.e. q_insert1 sampler - it will be executed only once per iteration.
I would also recommend re-considering language selection, since JMeter 3.1 it's recommended to use Groovy for scripting

JMeter: thread switching between variables for preset time periods throughout a test run

I have a script with a once only loop where a thread uses reg expression extractor to get a variable into an array. After the once only loop, the thread selects a random instance of that variable and then continues with that instance of the variable for the entire test run.
It would be more realistic for the script to do the following:
Jmeter thread uses variable_1 for x seconds, switch to variable_2 for x seconds, switch to variable_3 for x seconds
Variables_1,2,3,x coming from the reg ex array should be selected randomly
x seconds could be 300, 600, 1200 and selected randomly
Is this something that can be accomplished with JMeter controllers/functions or would it require something along the lines of custom beanshell code?
It can be done using ForEach Controller & Runtime Controller.
For Each controller is to iterate the variables one by one.
Under Runtime controller, you keep all your samplers to be executed for the duration.
Test Plan:
For Each Controller config:
Runtime Controller config:
I would recommend reconsidering your approach as this way you test won't be repeatable. The whole idea of testing is that when you run the test 2 or more times - you should get the same results, elsewise if you discover a product issue you won't be able to reproduce it to ensure that it is fixed.
Coming back to your question: yes it can be done via JMeter Test Elements without having to go into scripting. Take a look at __chooseRandom() function available via JMeter Plugins project. The easiest way of installing JMeter Plugins and keeping them up-to-date is using JMeter Plugins Manager

Using JMeter PreProcessor and User Variables logic

I am new to JMeter and it maybe a stupid question but I still find it hard to understand the concept here.
I have a simple test.
Thread Group with a Single thread with loop count of 2
PreProcessor that place two
variables on the vars map
A loop that execute a request twice based
on the PreProcessor parameters
I expected that the preprocessor will initialize the parameter and it will use the same values twice in the request.
It looks like it’s executing the PreProcessor once pair call.
When I switch the PreProcessor with similar User Defined Variables it reuses the same value on every call.
Can anyone explain the logic here?
I am using JMeter 2.11
A PreProcessor is executed each time the HTTP Request is executed so if you have a total of 2 iterations, you should see log twice, you have it 4 times so maybe number of iteration is different than what your write or you have 2 threads.
When you use User Defined Variables, the value is computed once and then reused. Value will be different per thread.
After reading the documentations and with #UBIK LOAD PACK help I used User Variables and it worked
User Variables - are specific to individual threads.
Pre-Processor is attached to a Sampler element (e.g. http request in our case), then it will execute just prior to that sampler element running
So 4 request for different parameters because it runs before every request
User Defined Variables - It is processed at the start of a test, no matter where it is placed. For simplicity, it is suggested that the element is placed only at the start of a Thread Group. This is why I get the same value all the time

jMeter - Beanshell bsh.shared hashmap data in init file?

I have a jMeter project I'm working on which has thrown up all sorts of problems. Mainly due to storing and scoping of variable data throughout the run.
I now have things pretty much working and I'm using a Beanshell shared hashmap to store data through the run. I don't need to worry about thread safety due to the way I'm doing it.
It works, but it re-initialises itself each time a thread group runs. Despite putting the initialisation step outside all thread groups.
So, as I understand it, the solution is to put all the startup data into an initialisation file which is only run once on startup. But I can't figure out how I'm supposed to do that? I've copied the code from the Beanshell Preprocessor I was using previously into a ".bshrc" file and updated the jMeter properties file with the location of my ".bshrc" file, but it doesn't seem to work. It doesn't actually seem to have done anything. When I run the test, no values are present and everything fails.
I've tried using:
beanshell.init.file=../bin/data.bshrc
and
beanshell.preprocessor.init=../bin/data.bshrc
I've tried to find some sort of idiots guide to setting up an init file, but I can't find anything helpful. This is the first time I've had to make much serious use of Beanshell and my Java knowledge is VERY limited at best!
At the moment, I'm getting round it by running my test once with the original Beanshell pre-processor enabled. This sets up the hashmaps and they stay resident in memory from there on. I stop this run, disable the pre-processor, and all subsequent runs work just fine.
Anyone?
I would suggest using setUp Thread Group which is being executed prior to any other Thread Groups and define your test data there with a Beanshell Sampler like
bsh.shared.myMap = new java.util.HashMap();
bsh.shared.myMap.put("foo","bar");
// any other operations
After that in your main Thread Group(s) you can access myMap values in any Beanshell-enabled test element (Sampler, Pre/Post Processor, Assertion) as
log.info("foo = " + bsh.shared.myMap.get("foo"));
2014/07/22 10:06:48 INFO - jmeter.util.BeanShellTestElement: foo = bar
See How to use BeanShell: JMeter's favorite built-in component guide for more details on Beanshell scripting in Apache JMeter and a kind of Beanshell cookbook.
If you use Beanshell for "heavy" operations I would recommend considering switching to JSR223 Sampler and Groovy language as in that case you'll get performance comparable to native Java code.

What is purpose to use setup threadgroup and teardown threagroup in Jmeter? Please explain same with example

What is purpose to use setup threadgroup and teardown threagroup in Jmeter? Please explain same with example.
I know why we use thread groups and also aware of fact that setup is for pre activities like creating user and monitoring purpose but not sure with an incident where can i use it. same with tear down.
It sounds like you have pretty much figured it out already, but let me give you a few examples of when I've used it.
setup:
Get a large data set from a database into a jmeter variable for use during the test.
Get and log the version number from the system under test:s version number.
Run a javascript to set jmeter properties based on more simple input parameters/properties. Lets say you want to configure the selection of target host a simple true/false value, but in your test you need to expand it to different strings, and you dont want to have logic spread out all over your test plan.
teardown:
Never used it, but I guess it is mainly useful for cleaning up your system (e.g. deleting users that were created during the test)
correct me as i'm probably wrong, but a setUp thread cannot be used to store variables for use on the test threads (that i can see). any variables that i use in the setUp are never available. however, i found that if i use a beanshell and convert the variable in the setUp thread to a property like this
${__setProperty(userToken, ${userToken})};
then on each test thread i either use the property directly like:
${__property(userToken)}
or at the top of my thread i convert the property back into a variable like:
vars.put("userToken","${__property(userToken)}")
however, this seems a bit long winded and it would be great if there was a way to set up variables in the setUP to be used on every thread.
A special type of ThreadGroup that can be utilized to perform Pre-Test/ Post-Test Actions.The behavior of these threads is exactly like a normal Thread Group element.
The difference is that these type of threads execute before/after the test has finished executing its regular Thread Groups.enter image description here

Resources