>Some elaboration or examples might be helpful. It's kind of vague to your >average user. We can only assume, and assuming isn't always good. No you should test :) But in general its vague because it depends. The basic recommendation is that using this sampler is inefficient(in terms of CPU/memory/execution speed) - i.e. there are faster ways to do the same thing. Whether this matters to your test is something only you can say.
Note what you are doing in JMeter is ultimately a simulation - you want it to reflect the true situation . Running 100 requests in parallel from a computer isn't going to be exactly the same as running a request from 100 different computers . Lets say you have a test which has 10 threads , plenty of delays between tests, samplers take reasonable amount of time - Most modern computers would be able to run this JMeter test and it would be more or less the same as running a single test in parallel on 10 machines. But what if you have a 1000 threads , no delays , your samplers return quickly and you are running it on some windows client box ? The load that this machine generates will not be anywhere close to what 1000 different clients would have been able to generate - your simulation wont match your actual. In the first case , it probably wont matter whether you use beanshell or not. In the latter case also , even if you optimise the test you probably wont get your simulation to match exact load. You might trade off the ease of writing beanshell with just adding more JMeter test machinesso that the fact that you use beanshell becomes irrelevant. or you might be running a test for which response times dont matter (perhaps a functional test or some other type of test). Or you might just want to write the most optimum script so that your simulation has a better chance of matching actual. In all cases , dont guess or assume - test it!. Look at the Jmeter client and see if its overloaded or whatever. One strategy that has worked well for me is if Im trying to simulate for e.g. 100 threads , I run it once from a single box. Then repeat the same test but use 2 independent JMeter instances with 50 threads each at the same time (not distributed mode). If the load my server sees is the same and my throughputs match , then all is well - if there is a significant difference then there might be a problem (and I need to add more boxes). Other times we access the site while the test is running and verify whether we are seeing similar times to what Jmeter is reporting etc. On Wed, Jun 1, 2016 at 5:41 PM, David Luu <[email protected]> wrote: > Just noticed this reading some stuff in the best practices section: > http://jmeter.apache.org/usermanual/best-practices.html#jsr223 > > "For intensive load testing, the recommended scripting language is one > whose ScriptingEngine implements the Compilable interface. Groovy scripting > engine implements Compilable. However neither Beanshell nor Javascript do > so as of release date of JMeter 2.13, so it is recommended to avoid them > for *intensive* load testing." > > I'm curious what "intensive" should be generally interpreted as: > > * when you see/know the jmeter machines being loaded on CPU and/or memory? > * at some typical X requests/sec throughput? > * CPU/computationally expensive operations/calculations? (on the jmeter > side that is, not the SUT) > * network or disk I/O expensive operations? (on the jmeter side that is, > not the SUT) > * attempting to test very low latency operations? on the order of X ms or > ns, etc., thus should equate to high throughput (if sustainable) > > Some elaboration or examples might be helpful. It's kind of vague to your > average user. We can only assume, and assuming isn't always good. > > I get the feeling beanshell and javascript are more popular with jmeter use > than groovy but I could be wrong. >
