Forum Discussion

ranjitloadui005's avatar
10 years ago

Increasing the Thread Count Of Load UI

In Load UI 2.6.6 and 2.7.0 we changed the internal thread value(Global Settings) values in workspace.xml file to increase the thread count. But this also does not ensure the stagnation of the tool in a composite run. In a scenario when we are triggering multiple request to the server and then observing (Open Windows Task Manager > Performance Tab > Resource Monitor) the overview , cpu section of it .When the no. of threads there increases above 545 or so for Load UI the tool stagnates. This results in achieving less throughput as desired and more often termination of tests. Currently the desired TPS is 1500 but we are able to reach 500 only because of the stagnation issue mentioned above.
Suggest the correct approach as changing the global settings also does not help in increasing the load on server.

1 Reply

  • Hello Ranjit,

    First we need to straighten something out.

    What is your requirement?
    Do your requirement specify that your server is supposed to handle 1500 Transactions Per Second (TPS) or does it say that you are supposed to handle 1500 concurrent virtual users (VU)? I can't stress how much this is two very different requirements and how they should be reasoned about.

    If 1500 TPS:
    Then having 1500 concurrent threads hammering your server does not solve your problem.
    That the thread managing the request is unique for that second has nothing to do with whether you can satisfy that requirement.

    Solve the problem
    If you set 1500 requests / second with a rate-component and investigate whether the server can handle them or not.

    If 1500 VU's
    Each thread will complete a request and immediately upon completion continue with another one.
    This makes it very hard to enforce that exactly 1500 users are running at the same time.
    Most of the time it only makes sense to do this when you have to put stress on a server continuously and then do some manual testing on the user experience of your service. This is simulated in LoadUI using the Load generators. see the link for usage as it needs an additional connector to the runner it is generating users for.

    Solve the problem
    If you set 300 load with a 200ms delay on a fixed-load component.
    This makes LoadUI only use 300 threads, which won't make Java unstable as seen in the link below.
    It will theoretically generate: ( 1000ms / 200ms ) * 300vus = 1500 VU's using 300 real threads.

    LoadUI
    Is written in Java, Java threads are very expensive to the virtual machine it is running in.
    Often, increasing the threadcount does not really help you in this endeavour in any other way than making the JVM highly unstable, keep this in mind when increasing internal threads like this. On maximum threads in Java

    This was essentially a summary of what is already written here.

    I hope this solves your problem.

    Best regards,
    Mikael