Forum Discussion

cbyndr's avatar
cbyndr
Contributor
16 years ago

load test strategy for iterating through datasource ten records at a time?

I have a test case set up as follows:

Datasource with 1000 records
Property Transfer
Request
Datsource Loop

From here I would like to create a load test that sends up 10 concurrent requests using 10 records from the datasource, waits for responses for all 10 requests, then moves on to the next 10 records in the datasource.

Is there some way to orchestrate such a load test with soapui, iterating through the datasource, and sending up unique requests, 10 at a time?

5 Replies

  • M_McDonald's avatar
    M_McDonald
    Super Contributor
    16 years ago
    From the user guide:

    "The "Shared" option in the toolbar control if the DataSource should be shared between threads during a LoadTest, meaning that all running threads will read from the same source of data instead of each creating their own."

    I think this means that each thread will cause the current row in the Datasource to be advanced.

    Though I could be mistaken.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    16 years ago
    Hi,

    you are correct. The tricky part here is how to wait for all threads to finish before advancing to the next 10, currently each thread just moves on to the next row when it is finished. I guess you would have to create a groovy script that could use some kind of synchronization-object in the loadtestcontext (initialized in the load-test setup script) to wait for all threads before moving on..

    regards,

    /Ole
    eviware.com
  • cbyndr's avatar
    cbyndr
    Contributor
    16 years ago
    great-- will go in that direction, and post again once i have the test up and running.
  • cbyndr's avatar
    cbyndr
    Contributor
    16 years ago
    Right, so, I ended up paring the datasource down to 10 records, and iterating through the same ten records by running the load test (iteratively) from the command line, using the load test's tear down script to clean up between iterations.

    Somewhat crude, and deviant from the idea behind my original post, but it worked for this test's purposes, which had been to produce a ConcurrentModificationException in an external application.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    16 years ago
    Here's a way of getting the desired functionality using setup/teardown scripts:


    //LoadTest Setup:
    context.monitor = new java.util.concurrent.atomic.AtomicInteger(0)

    //LoadTest TearDown:
    synchronized(context.monitor) {
     def monitor = context.monitor
     context.monitor = null
     monitor.notifyAll()
    }

    //TestCase TearDown:
    if(context?.LoadTestContext?.monitor != null) {
     def monitor = context.LoadTestContext.monitor
     def numWaiting = monitor.incrementAndGet()
     
     synchronized(monitor) {
      if(numWaiting >= context.LoadTestRunner.runningThreadCount) {
       monitor.set(0)
       monitor.notifyAll()
      } else {
       monitor.wait()
      }
     }
    }


    Regards,
    Dain
    eviware.com