SoapUI 4.0.1 slower than 3.6.1

Hello,

I just posted a message concerning this issue. If you think 4.0 is slow, wait until you try version 4.5. My thread is titled "Inconsistent load test results among SOAPui versions". I wrote the following:

Hello,

We are load testing our Web application with both SOAPui version 4.5 and JMeter, and using the same SOAP script and load test scenario on both applications. The load test is burst, with 20 virtual users running for 180 seconds and no burst delay. JMeter processed 1588 requests in 180 seconds and SOAPui 4.5 processed 482. This is a dramatic difference in load test performance results. The one thing that was noticed with JMeter is how it continuously sent requests to the server to the point where it filled up all of the available threads, resulting in requests waiting in the queue to be processed. When SOAP version 4.5 was testing, there were many less requests getting sent to the server for processing and no requests were waiting in the queue.

A co-worker with SOAPui version 3.6 tested the same scenario, and his results were consistent with JMeter's with 1521 requests processed in 180 seconds. This version also sent requests to the server like JMeter at a continuous loop rate, resulting in requests waiting in the queue to be processed.

These results had me wondering if there are significant differences in SOAPui releases. As a result, I installed SOAPui version 4.0. Version 4.0 about 55% more requests than version 4.5, but was still much lower than when testing with version 3.6. It processed 1026 requests in 180 seconds.

I had been using SOAPui for some time and always wondered why my results would be inconsistent with JMeter and my co-worker who was using SOAPui version 3.6. It appears that version 4.0 and 4.5 have defects in the way that it bursts virtual user requests. Why are the different versions of SOAPui producing dramatically different results?

Thanks for your reply.

I've noticed an big difference in these two patterns:

Pattern A
1. Invoke a service method --> 20 ms
2. Invoke a service method --> 20 ms

Pattern B
1. Invoke a service method --> 20ms
2. Invoke a script that conditionally reexecutes step 1, one time --> 2 ms
3. (reexecution of step 1) Invoke a service method --> 600 ms (back-end did not take 30x longer!)

It seems "something" connected with the conditional branching adds time which is being tallied to the 2nd invocation of the same service in Pattern B.

Makes looping and sending a continuous stream of sequential requests to a service with no pauses impossible.

Loop method (in groovy script after the first invocation of service)...

if( !context.hasProperty("myCounter1") ){
context.setProperty("myCounter1", 0)
}
def myCounter1 = context.getProperty("myCounter1")
myCounter1 ++
context.setProperty("myCounter1", myCounter1 )
if(myCounter1 < 2) testRunner.gotoStepByName("InvokeService");

Based on comments I guess I need to revert to SoapUI 3.6 to get continuous submission of requests in a loop? Strange.