ThreadIndex

Hello,

Thanks for reporting! This should be fixed in the next version of loadUI, and the next upcoming nightly build.

Regards,
Dain
eviware.com

We can work around the fact that the loadui threadIndex starts at 1 in our loadtest code for now.

When distributing a load test to multiple loadui agents, how does the threadindex vary? Does it go from 1 to N, n being the number of loadui agents there are? This is the expected behavior. If it doesn't act like this, how can you (from a context. variable) determine which loadui agent you are on?

Thanks!

Hi!

good point; actually you can't for now, I'll put in a feature request for this internally, maybe its easy to add. What kind of information regarding the agent would you like to have access to ?

regards!

/Ole
eviware.com

The only thing I can see that we really need is something similar to threadindex. For example, when we run a 20 thread test as a load test in soap-ui, we use the context.ThreadIndex variable to change some values in the soap requests we're making (for example, say user1, user2, etc)

If we're creating a distributed test for loadui, we usually stick with running one thread per agent (and then we have 20 VMs each running an agent) So, we want to be able to access something to identify the agent number (say context.AgentNumber) which works similarly to the ThreadIndex.

Does this make sense?

Thanks for your response! SoapUI+LoadUI are great!

Sorry for this very late reply.

I have to question your setup a bit, are you running 20 agents in 20 VMs on a single machine? The need for multiple agents is generally to distribute load to several physical machines when one isn't capable of generating enough load by itself. A single loadUI agent is capable of running several threads, as long as the hardware can support it. That said, loadUI doesn't really use the same thread model as many other load testing tools use, as it is not a very accurate representation of real world load, and isn't very efficient. Instead loadUI internally manages threads to provide the desired number of requests per second, or the desired number of concurrent requests (using the Fixed Load Generator). It sounds like you should be able to use a single loadUI agent with a rate 20 times higher than what you currently have. Again, since loadUI manages threads as efficiently as possible, if you're using for instance a "Fixed Rate" Generator it's likely that Thread 0 will handle most requests, and higher numbered threads will only be used if needed, so you won't get an even distribution of ThreadIndices.

One thing you should be able to use which is unique per machine is the hostname, which you can access using the following Property Expansion: ${=InetAddress.localHost.hostName}
If you need to make sure you have something unique for all agents and threads, you will have to combine the hostname and the thread index.

Regards,
Dain
eviware.com