loadUI doesn't create multiple TCP streams with soapUIRunner

Hi,

What about if you check the "Close connections between each request" checkbox in the soapUI Runner component settings? Does this result in the desired behavior?

Regards,
Dain
SmartBear Software

Unfortunately, closing the connection after each request does not produce the same behavior as soapUI either.

My test case is a sequence of HTTP GETs. Closing the connection after each request causes each HTTP GET to have it's own TCP port as if it were a separate connection.

It must be somehow coded differently within soapUI versus loadUI. The soapUI has the desired behavior... all the HTTP GETs that are part of the testSuite use the same connection (ie IP/PORT). This behavior gets changed once exported to loadUI. It appears that soapUIRunner tries to be "conservative" and squeeze as many threads as possible into the same IP/PORT. So if the socket is "busy", it moves to another TCP port.

Any ideas of what else may help to resolve this?

Also, just to add some clarification to this problem...

It appears that the soapUI behavior is "Each Thread is a IP/PORT", and this is desired. So basically, when I create a loadTest in soapUI, even though the TestSuite has many HTTP GETs in a row, each GET is performed by the same thread (ie User), so they all have the same TCP port.

So, it seems like something is different with the concept of the "each thread is a user" in loadUI. I notice that the naming convention in loadUI is not "Threads" but instead "Users" or "Rate". Something is different within the loadUI coding that causes the behavior to not be the same.

Hi,

The soapUI Runner in loadUI uses soapUI as a library when running a soapUI project, the difference lies in how load tests are managed. soapUI has a more simplistic threading model where each thread gets allocated up front and runs the TestCase the desired number of times. The actual handling of connections is done by HttpClient, a third party library. There is no code in soapUI to ensure your desired behavior, it seems like it's more of a fluke that it is working as you want it to. I'm not sure how HttpClient pools its connections (it's likely keeping one connection per thread), but it's likely that we could interface with it to ensure that the desired behaviour is achieved, though it may require a bit of effort, so please create a feature request detailing the exact behavior you would like to see and we'll see what we can do to accomodate it.

Regards,
Dain
SmartBear Software

yes, after studying the behavior awhile with loadTest in soapUI, it appears you are correct. The desired behavior in soapUI is basically a fluke, since sometimes I am seeing the exact same behavior as loadUI.

Basically, I'm trying to emulate the behavior of Firefox, or Internet Explorer. When these browsers are used, they seem to select from the pool instead of using the same 1 or 2 connections all the time.

Since adding a feature such as this may be very involved, or may not even be possible....can you think of a workaround for us? Such as, the "script strategy", is there a way to create the test in such a way that multiple TCP connections would be made?

The only alternative I know of is to simply close the connection after each request, but that is the other extreme.