loadUI only injects 2 requests simultaneously ?!

[opstalj]

Hi,

I am evaluating loadUI in order to see whether we will use it for our load testing.
For our test, I made a HTTP POST message and the idea is to stress test our application with it.
Therefore, I am using a fixed rate generator.
Problem is the following: despite setting a rate like 10/sec, loadUI only sends out 2 requests.
Once a reply is received, loadUI sends out a new request ...

I have checked already a lot of settings, but can't understand why loadUI does not send out 10 requests
per seconds as indicated in the fixed rate generator ?!

Any idea why loadUI is stuck at 2 requests simultaneously ?
Obviously, loadUI is now quite useless for us .

Interesting note: the test case that I am using in loadUI has been built with soapUI.
Strangely enough, I can run lots of load with soapUI ! (there I do not have the restriction of 2 simultaneous requests)
(I am running loadUI and soapUI on the same PC)

[SmartBear Support]

Hi,

Please note that sending 10 requests per second is not the same thing as how many requests that are running simultaneously. In soapUI, you usually set the number of threads -- that's a completely different concept. Requests per second is a more realistic approach than threads, which is why we use that in loadUI.

For example, if your server handles any request sent (under any load) in 1 nanosecond, and you send 100 requests per second to it, the server will at most have 1 request running at any point in time.


Useful reading 1
Useful reading 2

Regards

Henrik
SmartBear Software

[opstalj]

Hi Henrik,

Thanks for your fast response.

In fact, what I want to do, is exactly what you say: send 10 requests per second. No matter what the response time of the server is
(big chance that the response time will get bigger and bigger as the server has to handle more and more requests in a certain time frame).
So I want to see loadUI sending out 10 requests per second:
eg: if I start loadUI for 1 min at a rate of 10 req/sec, then I want it to have sent out 60*10=600 requests.

Any idea how I can achieve this ?

Do note that the request that I am sending out, typically takes around 10 to 15 seconds to be handled by our server.

Kind regards, Jan.

[SmartBear Support]

Hi,

Could you perhaps share a screenshot of how you have your test set up? What you describe wanting to do is exactly what loadUI was designed for, it should work like that pretty much out of the box.

Regards,
Dain
SmartBear Software

[opstalj]

Hi Dain,

In attach a screen shot of my loadUI setup. Pretty simple setup in fact: a fixed rate generator and soapUI runner.
Maybe something in the soapUI test case causes this issue ?

I am using:
- loadUI: 2.0.0
- soapUI: 4.0.1

Thanks already for your support.

[opstalj]

Any update ?
Thanks in advance.

[SmartBear Support]

Hi,

We've now confirmed this behavior, it is in soapUI 4.5, and thus, the soapUI Runner component in loadUI 2.0. This is a bug, and we'll hopefully have a fix for this soon.

Regards,
Dain
SmartBear Software

[opstalj]

Ok, thanks.

Can I be informed when the fix is available ?
Kind regards,

Jan

[SmartBear Support]

Hi,

This has now been fixed in our internal builds, and a workaround has been published. Please see this post in the soapUI forum.

Regards

Henrik
SmartBear Software

[opstalj]

Thanks !

[katgat]

I'm wondering if my issue is the same as this problem.

I am seeing different LoadUI results depending on the SoapUI version I use (at least that is the only difference I can identify). Using LoadUI 2.0.1 if I test with SoapUI 4.5.0 all seems to work fine with my load testing and results are as expected. We run 20 requests per second (fixed rate) and after 1 minute our application processes approximately 1200 requests. While LoadUI is running, the "Running" queue never really goes above 20 requests and none get queued. But with SoapUI 4.5.1, we only process about 895 requests in that same time period. When running the test, the "Running" queue maxes out at 100 and many end up being queued (in the hundreds). The two sets of tests (i.e. running one test with LoadUI 2.0.1/SoapUI 4.5.0 and then with LoadUI 2.0.1/SoapUI 4.5.1) are run back to back against the same web service that we are testing - so no difference in the web service code version that each one hits. I have compared the configurations and settings and everything looks the same. The only difference I see is using the different version of SoapUI. So I'm wondering if this is the same issue as described by the original post and that in the first instance where it seems to work for us it is really because it is just being throttled by the bug in SoapUI 4.5.0?