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 ...
Forum Discussion
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
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
