Asynchronous REST service

113 views
Skip to first unread message

Alex Albu

unread,
Dec 1, 2014, 5:13:07 PM12/1/14
to gat...@googlegroups.com
We are trying to load test an asynchronous REST service.  We'd like to measure not only HTTP response times, but also processing times, recorded by events generated as the original request is processed in the background.  These events are recorded in database tables and have timestamps.

What we currently have is pretty crude (it's our first attempt to use Gatling).  After executing the HTTP request and verifying it has returned successfully, we are looping (using asLongAs) until we observe the expected events (or we reach the max number of attempts).  We're storing the various event times in Gatling's session and are dumping the results in a CSV file at the end (we're fine with just recording data points and doing our own reporting).

I'd be interested in hearing suggestions for doing this the 'right' way.  Aside from not being particularly elegant, this approach has the drawback that it makes it difficult to simulate our real-life use case, where we have a fixed number of clients making requests as fast as they can (meaning they'll issue a new request within milliseconds of the previous request returning).  The problem with the way we have things rigged up is that a Gatling client waits until the request has been fully processed, before issuing a new one (as opposed to doing it as soon as the request has returned).  It seems like recording event times should not be part of the scenario, but we need an identifier from the response to identify the associated events.

Thanks,
Alex

Stéphane Landelle

unread,
Dec 2, 2014, 3:06:49 AM12/2/14
to gat...@googlegroups.com
Can't you store the request ids in a concurrent queue, and resolve the events when the simulation is done?

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alex Albu

unread,
Dec 2, 2014, 10:37:45 AM12/2/14
to gat...@googlegroups.com
When I thought of that solution, it wasn't clear to me where I would check for the events, if not as part of the simulation.  Looking a bit deeper, an 'after' block seems like a good fit.  Is that what you're suggesting?

Excilys

unread,
Dec 2, 2014, 10:43:27 AM12/2/14
to gat...@googlegroups.com
For example. Or even outside Gatling. How do you fetch the events? Web API? JDBC?


Alex Albu

unread,
Dec 2, 2014, 11:31:41 AM12/2/14
to gat...@googlegroups.com
JDBC.  I'd like to keep it all inside Gatling.

Stéphane Landelle

unread,
Dec 2, 2014, 11:35:57 AM12/2/14
to gat...@googlegroups.com
OK, so DON'T do it the way you've done it until now: JDBC is a blocking protocol (except if you're using some fancy driver, and then, you have to use it properly), and you're harming the load test.

Populating a concurrent queue, or dumping elsewhere (file, redis) during the run, then fetch the events once everything is done in an "after" block LGTM.

Alex Albu

unread,
Dec 2, 2014, 11:45:06 AM12/2/14
to gat...@googlegroups.com
I see.  Thanks.

Hyunil Shin

unread,
Aug 24, 2016, 9:23:48 PM8/24/16
to Gatling User Group
I'm in the same situation.
Could you describe how to measure the background processing time?
Reply all
Reply to author
Forward
0 new messages