In JMeter test plan, why do I need JDBC post (/pre)proecssor when I can just use JDBC sampler?
If the relevant sampler will be before/after the request it will be same as JDBC Pre/Post processor
Also it seems more reusable option
By default JMeter does not include the time required to execute any Pre Processors into sample result. Same applies to Post-Processors and Timers (unless you are using Transaction Controller configured to do so)
So I would use Pre Processor if it assumes some pre-requisities setup and I am not interested in its results timings.
If I need to measure the time required to execute a request - I would go for Sampler
Check out A Quick Guide to JMeter PreProcessors article for comprehensive information on using Pre Processors in JMeter tests.
Related
We have been using the Jmeter for the API's functional and performance test activities.
Is there a possibility to generate the documentation (similar java docs, API docs) for the JMX projects that we have been developing?
Each JMeter's Test Element has "Comments" section which can be used for explanation of what this element is for:
It's possible to create a JMeter Test Plan using Java language and JMeter API, see JMeter Command Line Overview: 5 Ways To Launch a Test for more details. There is also jmeter-from-code sample project you can use as a reference, normal JavaDoc will be available out of the box
There is JMeter DSL project which provides easy and handy way of creating a JMeter test plan, however it doesn't fully support all the features. For basic test plans it should be faster and easier than point 2
There is Taurus tool which provides possibility to create JMeter scripts in a declarative manner using YAML and YAML naturally supports comments
I've implemented a testing unit using spring (mock mvc), and I'm looking for a tool to run this unit in many threads/processes (so it will act as load testing for my server). I've seen applications like the grinder and jmeter but I don't want to re-write the entire unit, but just to use the existing one. Any ideas?
JMeter is able to execute existing JUnit tests via JUnit Request sampler, all you need to do is to drop jar(s) with your test along with dependencies somewhere in JMeter classpath and restart JMeter. Once done you'll be able to see your classes and methods in JUnit Request sampler dropdown and execute them in multithreaded manner.
See How to Use JUnit With JMeter guide for more detailed instructions and explanations.
I'm trying to use a JSR223 post processor in jmeter 2.11 with some java code and I keep getting this error:
org.apache.bsf.BSFManager:Exception:java.lang.ClassNotFoundException:org.apache.bsf.engines.java.JavaEngine
I've checked the bsf/bsh jar files, not sure what else I need to do to make this work. I've read that groovy is recommended but I'd really like this to work with java.
As per the very first lines from BSF Sampler documentation:
See the Apache Bean Scripting Framework website for details of the languages supported. You may need to download the appropriate jars for the language; they should be put in the JMeter lib directory.
And at the same place:
The BSF API has been largely superseded by JSR-223, which is included in Java 1.6 onwards. Most scripting languages now include support for JSR-223; please use the JSR223 Sampler instead. The BSF Sampler should only be needed for supporting legacy languages/test scripts.
So I would recommend considering the following (in the order from worst to best performance provided)
Beanshell Sampler (if your Java code is doing something "light")
JSR223 Sampler + groovy language - for "heavy" operations (again you'll need to have groovy jar in your JMeter CLASSPATH)
Write your own implementation of Java Request Sampler
Both Beanshell and Groovy support Java syntax with some limitations which can be easily worked around.
See Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! guide which might help you to make right selection.
Are Java Request samplers as accurate as SOAP or HTTP samplers in jmeter? For example, I run a java request sampler which reads from a csv file and handles entries in the file through code. This causes 0 throughput in the results.
However, when I use HTTP or SOAP samplers I get higher throughput since the entries of the csv file are handled one at a time through Jmeter not through the java code.
Any clues on how to solve this "inaccuracy" in the Java sampler results?
Related to this question is: if I use the Java Request Sampler Test class to merely call a static method in another java class. Is that a good practice or the whole logic should be inside the runTest method?
Thank you.
Java Request Sampler is pretty much alike any other sampler.
Make sure that you invoke sampleStart() and sampleEnd() methods at the beginning and in the end of your test.
See Java Request section of Beanshell vs JSR223 vs Java JMeter Scripting for example Java Request Sampler source code.
I there a possibility to access MBeans of the system under test from JMeter? I have a system which has several deployments, but needs a MBean call to do final initialization and startup. I need to access and run this. Addtionally, it would be great to get some information out off MBeans for testing.
How is this possible? Do I really need to write an own sampler?
To init your component you could use à jmeter setup thread group and use a jsr223 sampler using groovy as underlying package.
With groovy it's very easy to call jmx operations:
http://groovy.codehaus.org/Groovy+and+JMX
Otherwise there is a plugin:
http://code.google.com/p/jmeter-rest-sampler/
It contains a jmx sampler in it.
There's a project with a set of plugins for JMeter one of which supports JMX: http://code.google.com/p/jmeter-plugins/wiki/PerfMonMetrics#JMX_Metrics
The PerfMon mentioned above by mvmn will access MBeans of the system under test, but the preferred JMeter Plugin solution is to use the new JMX-specific plugin.
The following link shows how to identify a jmx metric in JConsole MBean tree (using ObjectName, attribute name, etc..) and then add that info to the JMXMon interface.
http://jmeter-plugins.org/wiki/JMXMon/