LoadRunner vs SoapUI: differences
I've tested a web-service with LoadRunner, 10 Vusers for 10 minutes. Leave out other metrics, but I have a lot of HTTP 500 error. I tryed also with SoapUI (usually I use it for a premilinary single web service call), simulating a load test with 10 Threads (in SoapUI that's the name for Vusers) and 10 minutes, but there aren't errors.
Can anyone explain me this particular behavior? I know that the logic of the test are different: LoadRunner use load generators unlike to SoapUI, but the results and some other informations about differences between two products are interesting.
Thank you very much,
Do you have LR running in the same machine as SOAPUI? I have seen such errors when there is a firewall between the LR machine and the host. From the LR machine, can you try to ping the loadbalancer or the app server (whichever comes first) and see if you can ping?
thanks for response. I've tested the application with LoadRunner and SoapUI from the same workstation, and I can ping the server machine.
As I sayd, inconvenience lies on performance differences: from LoadRunner I have some errors, but there aren't similar evidence from SoapUI.
Thanks for the help,
Do you run the vusers as a process? If not you can try it.
Hier is explained the Multithreading
The Controller uses a driver program (such as mdrv.exe or r3vuser.exe) to run your Vusers. If you
run each Vuser as a process, then the same driver program is launched (and loaded) into the
memory again and again for every instance of the Vuser. Loading the same driver program into
memory uses up large amounts of RAM (random access memory) and other system resources.
This limits the numbers of Vusers that can be run on any load generator.
Alternatively, if you run each Vuser as a thread, the Controller launches only one instance of the
driver program (such as mdrv.exe), for every 50 Vusers (by default). This driver process/program
launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments
of the memory of the parent driver process. This eliminates the need for multiple re-loading of the
driver program/process saves much memory space, thereby enabling more Vusers to be run on a
single load generator.
2. The following article could help by error 500 with SOAP
HTTP 500 and a SOAP Fault during replay of a Web Service script
Solution: Add "ExpectedResponse=AnySoap" in the web_service_call functions
thanks for the interesting response, and the use of the header "ExpectedResponse=AnySoap" is newsworthy in case of HTTP 500.
But my doubt was about the difference between results on LoadRunner and SoapUI runs: in the first case, I have some HTTP 500 error (even if I add the header "ExpectedResponse") but there aren't with SoapUI. This is strange, because the launch configuration (users/threads, duration, web service call) is the same.
Thanks for every type of help about this matter,
From your explanation I understand that you have this problem only by concurrent vusers in Loadrunner and for this reason I suggested to run the vusers as a process. (Runtime Settings - Miscellaneous - Run Vuser as a process)
I had forgotten to tell you that I have just tried a run with "Run Vuser as a process" option under "Runtime Settings" page from Controller...but the results is the same.
I'm curious to know why results are differents despite SoapUI see Vusers as threads, exactly as I handle multithreading in LoadRunner's runs.
Have you other ideas about this particular topic?
Thank you very much,