I want to simulate 60 messages/sec for 30min using gatling to am AMQ server. However application im testing is not able to consume more then 10messages/sec. So in this case the expected behavior if for Gatling to start building the queue. However this is not the case. No messages are queued so it appears as if gatling is sending 60messages/sec and my componet consumes 60messages/sec but in the report it says Mean reqs/sec 10.
This is the relevant code. What can be the problem why Gatling is no building the AMQ queues???
val jmsConf = jms
val postJmsMessage = exec(
reachRps(60) in (20 seconds),
Yes but I have the same problem even if I use:
constantUsersPerSec(60) during(loadTime) randomized)
Still gatling puts alot of users in active but no queue is building up? What is the defenition of an active user in Gatling jms? Is it a user that has executed its scenaro and waiting for reply?
Because you have configured 10 listener threads.
The Gatling JMS support was contributed on top of JMS blocking API (receive).
I wonder how better it would be based on a MessageListener.
Still dont understand why no Queues are building? How are your answeres explaining why Gatling are just putting users in active state at the rate specified in load test, this is of no help in a load test. I want to know that messages are sent to AMQ at the rate specified in the load test but this is not the case with Gatling? I have increased the number of gatling jms listeners but no difference? So are you saying that JMS can not be tested at faster rates using Gatling?
I know that some people have been using Gatling at much higher rates than what you mention.
As long as you don’t provide a reproducer/test case for your problem, we’ll only be playing riddles.
Then, Gatling JMS support currently aims at request-reply pattern and measures “transactions”.
How can i configure how many threads should be used when posting messages using JMS since it seems all the JSM actors are just waiting for some comon threadpool.