we are using Gatling 3.4.0 to load-test an application that is interfacing via IBM MQ. Communication is Request/Reply based. Everything works fine until we cross ~ 75 requests/s (we’re using throttling for fixed rps) when Gatling apparently can no longer keep up with reading the response queue on which messages start piling up (until it eventually reaches the maximum queue depth). From that point on, Gatling OTOH is starting to record most messages as KO after crossing the 10 s request timeout.
Is Gatling consuming replies sequentially or in parallel? If the former is the case, is there any way to get it to do so in parallel?
Any idea how to further isolate the cause of this behavior?
A slightly redacted version of the simulation in question is available at: https://gist.github.com/ginkel/032d8332405d211eb06a5e0dcc85a252
I ran a test against Artemis and got a throughput of ~20k rps (request-reply scenario, small payloads, Gatling and JMS broker on my MBP).
So my first guess is that there’s something rotten in the kingdom of IBM…
thanks for the speedy reply. I have built an SSCCE , but while further debugging the issue it became apparent that replies were unintentionally sent persistently. After changing this to non-persistent, I can no longer reproduce the issue. I guess, I was probably DoSing MQ…
Thanks for your help!
Thanks a lot for your feedback.
By the way, would you be interested in contributing some documentation regarding settings for IBM MQ, based on the sample you provided?
We frequently have questions from people trying to configure their ConnectionFactory, figuring out which jars to add to the classpath, etc… and that’s not something we can help with.
I’m not an IBM MQ expert myself, but I’ll grab a colleague and we’ll see what we can do. We also thought about open-sourcing a library with the various decorators required to get this working (to inject the IBM-MQ-specific settings).
It may take a while, though, until we have something ready…
Thanks for considering. Please keep us posted