Ever wondered how the counters in the Runner Component's displays are calculated? Below is a flowchart that formally shows how it works!
2. Thread pool size
Internally loadUI maintains a pool of threads that it uses to dispatch messages sent between components which in most cases allows for better resource management than when allocating one thread per simulated user. There are a number of settings and behaviors to be aware of related to this when running your tests.
Global execution settings are set from the Workspace Settings dialog in the Execution tab:
The "Max Internal threads" setting controls the total maximum number of simultaneously running threads, increase this value if you for example plan to have more than 1000 requests executing at the same time (not in sequence). If you do not and your test for some reason requires more than 1000 threads it will simply block execution until threads are made available by allocating components. The "Max internal thread queue size" setting controls how many actions that will queue and wait for an available thread, additional actions (for example a request) will be discarded, this is to avoid running out of memory if some part of a test consumes all threads (as configured with the first setting) while others are still generating messages, etc.
Correspondingly this can be set for an agent from its settings dialog:
Increase this value here as well if you plan to run more than 1000 threads in a TestCase deployed on an agent.
Some Runner Components have settings related to how they execute, queue and discard trigger messages received from a Generator component:
(for the soapUI Runner these settings are available in the Advanced tab only)
By default both Runners will start up to 100 simultaneous requests (as can be seen on the “Running” counter on their display), any trigger messages received after that will be queued internally and dispatched as currently running requests finish (the Queued counter). When the Queue fills up to the configured Queue Limit setting, incoming trigger messages are simple discarded (the Discarded counter), the reason for this is to avoid running out of memory if a service simple cannot handle the number of incoming requests.
If you want your service to handle more than 100 simultaneous requests simply increase this value accordingly, but make sure that if you increase it over 1000 you will also need to increase the global Thread Limit described above, otherwise this limit will stop you from going over 1000 (since each running request requires one thread).