I was stress testing an application with JMeter when I discovered that the bottleneck was in the application setup rather than the actual application logic. My first reaction was to use a ramp to spread each thread’s application setup over time with a throughput controller as a starting gate once all the threads had been properly initialized. But the throughput controller wasn’t working for me, so I tried a BeanShell Timer instead.
My plan was to use a variable length delay for each delay. If the application setup was roughly constant for each thread, then I could let all the threads enter the application logic at roughly the same time. I was unable to find an good example of a BeanShell Timer using both arguments and environment variables, so I decided to document mine. The number of threads and the startup ramp duration were established as User Defined Variables, allowing them to control the Thread Group and to be accessed by my BeanShell Timer via a vars.get(parameter-name). The thread loop counter was passed into the Timer as an argument, accessed via bsh.args .
Getting the proper delay was easy once I determined how to access the number of threads, ramp duration and thread loop counter. Take the JMeter BeanShell Timer Test Script for a test ride.
1 2 3 4 5 6 7 8
count = Integer.parseInt(vars.get("ThreadCount")); ramp = Float.parseFloat(vars.get("RampPeriod")); num = Integer.parseInt(bsh.args); Integer sleep = 500 + 1000 * (count - num) * ramp / count; log.info( "Sleep for " + sleep.toString() + " milli-seconds" ); return sleep;