Dear Gatlers,
Was a bit disappointed by the way Gatling responded to my stress test for one of my play applications.
The test bombed with “java.net.ConnectException: Connection refused” where as my play netty server was keeping good health.
My lap configurations are as follows:
OS : Windows 7 Enterprise 32-bit
Processor : Intel Core i5 @ 2.5 Ghz
Core # : 2
Thread # by each core : 4
Memory: 4gb ( 3.42 gb usable)
My Fetch.scala are as follows:
Well…
First, being disappointed that dealing with 10.000 concurrent connections, opened in 1 second, with both the client and the server on localhost is a bit harsh, don’t you think?
Then, “Connection refused” means exactly what it states: that the server (Play) couldn’t keep up with the client (Gatling).
Finally, note that both Play and Gatling use the same underlying NIO engine (Netty 3).
Stéphane
That’s not a stress test, that’s a spike test 
If you really want to learn something about when this starts failing … ramp up gradually.
I think someone needs to read a few things from our standard performance testing library … like:
http://queue.acm.org/detail.cfm?id=1854041
http://queue.acm.org/detail.cfm?id=2413037
Totally agree with Stéphane - establishing 10.000 connections in 1 second is rough stuff for a windows machine - a device like f5 bigip would probably handle this better.
If you use gatling 2 instead, you can try a
rampRate(10 usersPerSec) to(10000 usersPerSec) during(10 minutes)
instead (the api looks a little bit different on master)
https://github.com/excilys/gatling/wiki/Gatling-2#wiki-inject
Stefan
No errors in play log at all - stuff like running out of sockets or something?