In loadUI components are the building blocks of your load tests; drag them from the Component Toolbar to the Project or Scenario view, connect them by dragging wires from and to their connection terminals and off you go! Since you can create and connect any number of desired components, you can easily and interactively simulate complex Load scenarios to test the performance and stability of your target system. And since all changes to components, connections and everything else is applied in real-time to an executing load test, you can interactively learn and probe the performance profile or your system under test.
LoadUI is designed to make it as easy as possible to create and share your own components (a developers guide can be found here). Click on Get more components at the bottom of the Component Toolbar to browse components posted to the online components repository.
But for now, let's have a quick look at the default set of components currently available in loadUI to see how they all fit together.
1. VU Generators
Generators are components that generate messages used to trigger runners; you usually connect the output of a Generator to the input of one (or several) runners. Alternatively you might connect its output to a splitter (see below) to divide the load between multiple target runners. The following generators are currently available:
From left to right these are:
- Fixed Rate — generates a steady flow of trigger messages as configured.
- Ramp — increases the rate of generated trigger messages as configured over time.
- Random — randomly varies a specified base rate as configured, use this for more realistic variations in base load when testing web pages.
- Variance — varies the generated load over time as configured.
- Usage — basically the same as Fixed Rate but with a different algorithm. Specify the number of users you want to simulate and the duration between each request they make. For example if you set this to simulate 1000 users with a page interval of 30 seconds this generator will output 33 (1000/30) trigger messages per second.
- Fixed Load — generates a fixed concurrent load of samples from the connected runner, for example if you want to ensure that you always have 10 samples executing simultaneously use this generator by connecting its output to the target runner and the output of the target runner to the second input of the generator (so the generator "knows" when it should trigger new samples).
Runners are the components actually performing some kind of action against your target system and outputting the results, for example sending a Web Page request or executing a soapUI TestCase. To get you started there are four runners available:
- soapUI Runner — executes a specified soapUI TestCase, which in turn can do any kind of complex tests as available in soapUI and soapUI Pro: SOAP, AMF, JDBC, REST, cookies/sessions, etc. This runner makes it possible to load test almost any kind of system.
- Web Page Runner — sends a web (http) request to the specified URL and measures the response time (read more).
- Script Runner — Runs a Groovy script.
- Process Runner — Runs an Operating System process/executable.
Runners will handle any incoming message as a trigger and use any parameters in the incoming message as applicable. They will have at least two output terminals, one for publishing the results for each request and one for publishing the current number of running requests (a new message is sent every time this number changes).
The available runners all have the following display panel:
The counters displayed are (a more technical explanation of these can be found here):
- Requests — the number of sent requests.
- Running — the current number of running requests.
- Completed — the total number of finished requests.
- Failed — the number of failed requests (it is runner-specific what qualifies as a failure).
- Queue — this is the number of queued trigger message; the maximum number of simultaneous requests can be configured in the runners settings dialog. If this limit has been reached incoming trigger messages will be queued.
- Discarded — once the queue is full (its max size is configurable in the settings dialog also) incoming trigger messages will be discarded. This is to avoid the filling up of memory over time if the number of trigger messages is constantly higher than the rate the target system(s) are able to handle.
All runners have at least two outputs (as seen in the Web Page Runner above, from left to right):
- Results Output — outputs a message every time a request finishes with basic request properties; timestamp, timetaken and size.
- Currently Running — outputs the current number of running requests, this is to be used with the Fixed Load Generator that will maintain a constant number of running requests at the same time.
Flow components are used to control the flow of the test execution, for example to divide load between different components, filter messages, etc. There are currently two router components available:
- Splitter — divides incoming messages evenly or randomly between the configured output terminals, allowing you to for example split the trigger messages from a VU Generator to go to different runners.
- Delay — pauses the incoming messages for the configured time, for example you could put this between two web-page runners which would delay the sequential execution between them.
- Condition — routes incoming messages to either the left or the right output, depending on if a condition is true or false.
- Loop — keeps passing each incoming virtual user to the left output, until they have been passed there X times.
Scheduler components are used to control VU Generators and VU Scenarios, allowing you to schedule when a component of such kind should be On and Off. This makes it possible to combine Generators, e.g. start with Ramping up, then Random Generator, and finally Ramping down with another Ramp Generator.
The schedulers bundled with loadUI are:
- Interval — scheduling based on time intervals, for example: On for 5 minutes and then Off for 30 seconds, repeat.
- Scheduler — scheduling based on a calendar, for example: On between Monday 17:00 to Tuesday 09:35.
Output components are for output messages from any other component to some destination. There's just one component bundled with loadUI in this category:
The TableLog is useful for visualizing individual results, messages, etc. It has settings allowing you to write its contents to a properties file, making it a good option for logging responses, VUs that failed a certain condition, etc.
This is a catch all category for components that do not fit anywhere else