I’m running Gatling 2.0 on Windows 7 and try to simulate a large number of users hitting our server. When I run my Gatling test with 20000 sessions, I get the following errors a few minutes after the test starts:
java.net.ConnectException: No buffer space available (maximum connections reached?): connect
The number of connections by querying netstat (netstat -an | wc -l) during the test has an upper limit of 16489. And then I try the same test on a Windows 2008 server r2 machine, the limit is around 10107.
Is there a limit of open connections on Windows? Or is there anything else that is preventing Gatling to have more sessions?
Any suggestion is appreciated.
I read this page while I was Googling for a resolution too… but I ran “net config server” on both my local Win7 and my Windows 2008 server machine, they return the same Maximum open files per session (16384), however, the actual limit when I ran the test was different. (see above)
Also, I don’t find a way to change that number…
You should ask on a Windows forum…
After a few days of researching I still have no luck changing the limit on Windows. So I decide to live with it.
However, even if running with 1500 sessions, the number of TCP connections keep going up and eventually hit the upper limit. Why is the connection not closed after the session finishes? I tried to set “allowPoolingConnections = false” and “allowPoolingSslConnections = false” in gatling.conf and it doesn’t seem to help.
However, even if running with 1500 sessions, the number of TCP connections
keep going up and eventually hit the upper limit. Why is the connection not
closed after the session finishes?
They are closed after the session finishes.
I tried to set "allowPoolingConnections = false" and
"allowPoolingSslConnections = false" in gatling.conf and it doesn't seem to
Your issue is probably related to TIME_WAIT
I don’t think I made any changes but when I run my script again this afternoon number of TCP connections do not keep increasing anymore… so it could be some issues with the server side (maybe the server didn’t close the connection?)
Anyways, thanks for the help on these topics.
You should probably check the state of your TCP connections, like those in CLOSE_WAIT.