Over the past few months, I've carried out more performance testing than I'd have chosen to, mostly against PeopleSoft in different environments. There are a number of sites that gave me useful tips to get through the process, and I thought I'd share them here.
It's also useful to know what breaks :)
About JMeter
JMeter is an extensible Java based tool to conduct various different types of testing, including functional, regression, load, soak and stress testing. Tests are controlled either from a graphical user interface or from the command line, and the ‘master’ host can control several ‘injectors’.
JMeter is an open source package from the Apache Software Foundation. For this project, it carries several advantages:
1. It carries no license fee
2. It can be extended
3. It has a fairly simple user interface
4. It supports multiple test injectors, required to push the system to its limits
JMeter is not a perfect tool, and has some disadvantages too, such as a slightly buggy user interface and slightly sparse reporting capabilities. Despite this, it is the best of the crop of open sourced options. Utilizing third party plugins can mitigate the sparse reporting.
My PeopleSoft test plans generally follow this structure:
Basically, this test will just perform a login. It includes a bunch of required elements for any PeopleSoft test - it extracts a session variable using a regular expression, ICSID, which you can use in other test elements further down, it includes a cookie manager (set to 'compatibility mode' - default setting will not work), and it includes a sampler to 'grab test data' - this accesses a simple web service I wrote that provides a row of test data in XML format - this adds next to no additional time to the test, but is really useful because when testing using multiple test injectors, it means that I don't need to copy data across to each server.
Recording the test is reasonably straightforward, but there are some gotchas. Firstly, you want to add an HTTP proxy element to the 'workspace' element, and set that up to use HTTP Client for the HTTP samplers. You also want to add some variables to a config element, including the PeopleSoft environment name, host, port, and protocol. For example:
1) PsEnv=DMO
2) host=localhost
3) port=80
4) protocol=http
If you do this, then when the proxy is recording test elements, it'll automatically replace DMO with ${PsEnv}, etc., saving an awful lot of time processing your test afterwards. You'll also find that most processes in PeopleSoft actually entail multiple GET and POST requests to the same URL. When you run your test, these will get grouped in the results. You can tell JMeter to prefix each sampler name with a counter by editing the JMeter.properties file.
An article on how to configure the ICSID parameter is here: http://www.erpassociates.com/peoplesoft-corner-weblog/utilities/using-jmeter-for-peoplesoft-performance-testing.html
With the ICStateNum parameter, if you leave it in your tests, you'll get the login page all the time. It seems to be OK to simply remove it from tests.
When you're looking at results, always add a 'View Results Tree' element while you're developing the test - this will allow you to see individual HTTP requests and responses (rendered as HTML!). This is incredibly useful.
If you decide to add 'user wait time' to your test, so you can pad out a transaction to take about as long as a real user would take, be aware of the scope of timers in JMeter. If you have a sampler followed by a timer, followed by two more samplers, then each sampler will get the same delay added. This is probably not what you want. Instead, add timers as child nodes for a sampler you want to have a delay after.
I also found the following useful:
- http://javaworks.wordpress.com/2010/06/15/functions-in-jmeter-bean-shell/
- http://www.javaworld.com/javaworld/jw-07-2005/jw-0711-jmeter.html?page=1
- http://code.google.com/p/jmeter-plugins/downloads/detail?name=JMeterPlugins-0.4.1.zip
Especially the last item - JMeter plugins has some very useful charts, including threads over time - if your test uses many injectors, this is a useful way to see when your test is ramped up, and if there are problems with the injectors failing.
Finally, it's a good idea to run JConsole against your injector JVMs. This will give you a feel for how much load you can push through from a single host. In our tests, with user wait times, we found we were able to push through 800 to 1000 users (threads), each with user wait time. All this took was to tweak the JVM heap size in the jmeter.bat file, since the servers we were using as injectors each had plenty of CPU power and memory.
