What I have done:
The application under test basically reads from in-mem cache respond with cache valued string as a json. invalidation takes place every ~15 minutes.
I looked into these config params from ‘https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Scala/play2-scala/play2-scala/conf/application.conf’ and copied them to my application.
I want to see how the application behaves under load(more rps and more concurrency).
So, the initial stress test resulted like
(with no timeout)
concurrent connections 500, resulting in ~1.5k rps with average latency of 350ms
concurrent connections 5000, resulting in ~5k rps with average latency of 3s
concurrent connections 8000, resulting in ~5k rps with average latency of 3.4s
As you can see stress tools(wrk, jmeter, k6) seems to be limited by play’s rps.
Also, the increase in concurreny is not resulting in increase of rps but is effecting the latency.
Am i using the wrong tools? Are there any other configuration params I should be looking at like vm’s tcp configurations etc?
Did anyone try to stress test a play application?
which configuration parameters of netty/akka http server or play config as a whole should one be looking at?
Please correct me if I am totally looking at this the wrong way