Improper scalability testing can give you the wrong idea about changes you've made to your BA Server instance.
Before testing, ensure that you're reusing sessions, instead of creating successive new sessions. Creating multiple unnecessary sessions causes the BA Server to run out of memory unless the session timeout in web.xml is set extremely low (1 per minute, for instance); the default is 30 minutes.
Logging into the BA Server is resource-intensive: you must authenticate the user; create a bunch of session data; and run all startup action sequences, which usually store data in the user's session. So if, during testing, you simply string together a bunch of URLs and ignore the established session, you'll create a series of 30-minute sessions and almost certainly run out of memory. The correct way to test the server is to mimic a user's actions from a browser. The sections below explain how to do this.
Sessions and URLs
Most stress test tools (Loadrunner, JMeter, etc.) have session/cookie management options to ensure that they behave like a human user. However, if you're creating your own test scripts, you should follow this process:
- Log into the server
- Execute a URL that contains the userid and password parameters (&userid=administrator&password=password for example)
- Using the same session, submit other URLs that don't have the userid/password in them.
Use this process for as many users as you need to test with.
To log out of a session, you can use the http://localhost:8080/pentaho/Logout URL; this will invalidate the session if you append the userid and password values of the logged-in user. Without passing those parameters (or, alternatively, specifying the session ID or cookie) on the Logout URL, you will create another new session instead of closing an old one.
This means that two back-to-back wget commands in Linux will create two different HTTP sessions on the server unless one of the following conditions is met:
- -cookies=on is specified for both wget commands
- -save-cookies is used on the first wget command to save the cookies to a file, and -load-cookies is used on the second wget command to load the session state
Memory and sessions
Out of memory errors in the BI Platform can happen because of what your test script is doing, not necessarily because of any weakness in the platform. You can see just how robust the BI Platform is by taking a look at a production server's natural (human user) load. The following URL will show you what each day's maximum and present number of HTTP sessions are: http://testserver.example.com/pentah...ic/UserService.
You can see the Java virtual machine memory settings by examining the the options passed to the Tomcat or JBoss start scripts, or by looking at the CATALINA_OPTS system variable, if there is one. The Xms and Xmx options define the minimum and maximum amount of memory assigned to the application server. The default settings are not particularly high, and even if you've adjusted them, take note of the number of sessions it takes to use up all of the memory. Also take note of the fact that closing sessions after an out of memory error will return the memory to the available pool, proving that there are no memory leaks or zombie sessions inherent in the BI Platform.