Contributions
Re: loadUI doesn't create multiple TCP streams with soapUIRunner
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.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions902Views0likes0CommentsA method to have threads select from a pool of TCP Sockets
We are attempting to perform a loadtest on our web server. The test involves queries to the webserver from a webpage made up of five to ten dashlets with information in each dashlet from the servers database. So basically, the client uses 2-3 TCP connections to the server using HTTP GETs to fill the information for the dashlets. I'm currently having trouble getting soapUI to emulate this behavior. I created a TestSuite that has five steps, each test step is a HTTP GET. This partially works, but the problem is only one TCP connection is opened. If I select "close after each HTTP request", then five TCP connections are opened. So both behaviors are incorrect for our testing. Is there a way to create a "pool of TCP sockets" so that we can select the number of TCP connections (i.e. ports) to use during the testing?13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.1KViews0likes1CommentRe: loadUI doesn't create multiple TCP streams with soapUIRunner
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.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions902Views0likes0CommentsRe: loadUI doesn't create multiple TCP streams with soapUIRunner
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?13 years agoPlace ReadyAPI QuestionsReadyAPI Questions902Views0likes0CommentsRe: soapUI allows concurrent users but loadUI does not
Just to add some additional information... I run wireshark on my PC to capture the traffic that is generated by soapUI versus loadUI. For the soapUI capture, I see many concurrent TCP conversations all happening simultaneously. However, the same testcase exported to loadUI only has two concurrent TCP conversations simultaneously. Maybe some can tell me what I need to change in soapUI so that when I export to loadUI the behavior is the same. Thanks.499Views0likes0CommentssoapUI allows concurrent users but loadUI does not
This is an interesting issue I am seeing with soapUI versus loadUI. I can create a testcase in soapUI with several HTTP GETs. I can then export this to loadUI to run there as well. When I run the test in soapUI, the HTTP GETs all run simultaneously. However, when running this test in loadUI, the HTTP GETs run sequentially. Is there some setting that I need to change so that soapUI and loadUI operate the same way?918Views0likes2CommentsloadUI doesn't create multiple TCP streams with soapUIRunner
Different behavior in loadUI versus soapUI. I created a loadtest in soapUI, I see that each "thread uses it's own IP/Port". That is ideal behavior. When I export the soapUI testcase into loadUI, the thread concept is not the same. Basically the soapUI Runner tries use the least amount of TCP streams (i.e. IP/ports) even with multiple users. Basically, I want the soapUI Runner to operate the same as the Web Page Runner. If I perform 10 step/sec for webpage runner, each "user" has a different TCP port. What do I need to do for the soapUI Runner so that it also uses a different TCP port per user?13 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.5KViews0likes5CommentsRe: How to indicate the teststep that failed with soapUI runner
*Resolved* On soapUI runner, go into settings and change the Output Level to TestCase and RequestTestSteps Place a Condition module on the Workspace and set condition to false Feed the soapUI runner output into the Condition Module Feed the Condition Module output into a Table Log Now the Table log will show the step that failed.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.2KViews0likes0CommentsHow to indicate the teststep that failed with soapUI runner
Is there a way that loadUI can report what teststep failed when using soapUI runner? I see that an assertion is reported as failed, but the user in loadUI does not know which step failed.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.7KViews0likes3Comments