The Web Performance Load Engine is an optional component of the Web Performance Load Tester software that runs Virtual Users - thereby generating more load against the server(s) than would be possible using only a single machine.
There are 3 types of load engines. The first is described on this page. Follow the links below to learn about the other load engines.
Installers for Windows, Linux and Solaris are available on our website. On Windows platforms, a GUI will lead the user through the installation process. For Unix systems, the installer will run on the command line. For example:
chmod +x LoadEngine_Linux_N.N.NNNN.bin
./LoadEngine_Linux_N.N.NNNN.bin
The installer may also be run without a UI or any prompts. This silent installation option will use all the default installation settings:
LoadEngine_Linux_N.N.NNNN.bin -i silent
Starting a load engine is similar to starting Web Performance Load Tester. On Windows platforms, there is a menu item labeled Load Engine in the same location as the item for starting Web Performance Load Tester. This starts a console window. When the load engine has finished initialization, a message appears in the console window reading Load Engine started. Entering quit in the console window stops the load engine and closes the window.
The load engine is started on Linux and UNIX platforms using the installed shortcut or the startup script:
/usr/local/bin/WebPerformanceLoadTester_N.N/LoadEngine
In many cases, the engine and controller will be able to immediately connect to one another, and will even automatically detect one another if they are both connected to the same local LAN. This section outlines the configuration options available for the engine, should an error be received while attempting to connect to it.
In order to connect to a Load Engine, the engine will need to be able to accept connections from the controller on at least one network interface. The IP address and port number used to accept connections may be controlled by using a plain text editor to edit the file "system.properties" (creating it if it does not exist), located in the directory where the engine was installed. The following lines may be added:
EngineRMIAddress=192.168.1.62 RmiRegistryPort=1099 RmiEnginePort=1100 EngineUserCapacity=5000 StartingRemoteEngineUserCapacity=1000
These values have the following effect:
Additionally, it may be necessary to specify the public IP address from
which the engine will be accessed, especially if that IP address is assigned
to a NAT or firewall device other than the engine itself. This may be
specified by editing the file "Load Engine.lax", and adding
the option:-Djava.rmi.server.hostname=site.mycompany.com
to the end of the "lax.nl.java.option.additional" entry in the
file.
For example:
lax.nl.java.option.additional=-Djava.library.path=lib32 -Djava.rmi.server.hostname=site.mycompany.com
If the "lax.nl.java.option.additional" entry does not already exist, it may be added to the end of the .lax file, along with a blank new line after the entry at the end of the file.
Once all of the settings have been entered and saved into the appropriate files, the engine may be restarted in order to pick up the correct settings.
In order to access an engine behind a firewall, it may be necessary to configure the port settings used by the engine for accessibility. The RmiRegistryPort and RmiEnginePort should be set, and the firewall should be configured to allow connections through these ports. For more information on configuring your firewall, please contact your network administrator.
After configuring the ports and starting the engine, the engine is ready to be added to the controller. The Engines View may be used to add a remote engine. When prompted, the IP address should be an address the controller can connect directly to. If your firewall uses a NAT, then this is the IP address of the firewall; otherwise it is that of the engine itself. The port option must be the same as the value of the RmiRegistryPort configured on the engine.
When a Load Engine is running low on available memory, it will stop adding Virtual Users to the test. To increase the memory allocation used by the engine, please see the section on Configuring Memory Usage.
Once the controller has been able to successfully connect to a Load Engine, the engine may be managed through the Engines View.
In some cases, it may be desirable to manually determine how many VUs will run on each engine, rather than allowing automatic distribution. However, since overloading an engine can result in collection of load test data that may be invalid, it would be unwise to override the distribution completely.
Each remote load engine has a configuration file (system.properties) in the installation folder. in this file, find/add this line:
EngineUserCapacity=NN
(for the local load engine, see the Configuration Files section for the location of the system.properties file)
Change the value of NN to reflect the number of total users that is desired for this engine. Repeat this for each engine and restart the engines. This setting will place a maximum limit on the number of users the engine will report that it can support. Since the controller will not allocate more than the reported capacity to each engine, manipulating these settings will allow manual selection of the distribution.
Note that the capacity of the engines will always be reported as "100" when a test is not running. Also, the reported capacity may be lower than configured, based on the CPU and memory utilization as analyzed by the overload prevention feature.