Problems while testing node.js server with siege
I was doing load testing for my node.js server (small webapp) using siege. I could see that for even a small number of concurrent connections like 300 it found some errors
siege -c 300 -n myserver.com:3000
Then I could see some results like
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer
I saw that the server is closing connections. Why is this so. How can I debug it. I have a server running on a Macbook pro with 4GB of memory. I want to inform you that I was using websockets. That is, clients visit the page returned by a web server running node.js. This page then uses web ports to connect to the same server for two-way communication. What could be causing this problem?
source to share
When faced with a situation where you believe that you may be running out of sockets, you need to confirm two things.
- Make sure you close your sockets explicitly. In some languages, the garbage collector termination logic will clean up after you, but this is latency and sloppy; in other languages that don't, your application will leak sockets (and thus files) until it exits.
- Make your OS so your application user account has enough peak sockets for your test.
To point out point 1: Are you closing your sockets? I'm not a heavy node.js user, but I think:
var conn = new net.Socket();
conn.destroy(); //Are you doing this?
To indicate point 2: set the hard and soft open file limit to something high enough not to get in your way:
launchctl limit maxfiles 8192 8192
Running sudo launchctl limit
without arguments should output your current limits. See Apple documentation for launchctcl for details .
source to share