Issues while testing a node.js server with siege

I was doing some load testing for my node.js server(a small webapp) using siege. I could see that for even small number of concurrent connection like 300, it showed 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 could see that the server is closing the connections. Why is it so. How can I debug it. I have a server running on Macbook pro with 4GB memory. I want to let you know that I have used websockets. That is the clients visit a page returned by the web server running on node.js . This page then uses websockets to connect to the same server for two way communication. What could cause such issue?

When running into a situation where you belive you may be running out of sockets, there are two things to confirm.

  1. Check that you are closing your sockets explicitly. In some languages the garbage collector's finalization logic will clean up after you, but this involves lag and is sloppy; in other languages that don't do this, your application will "leak" sockets (and thus file handles) until it terminates.
  2. Make your OS allows your application's user account enough peak sockets for your test.

To address point 1: Are you closing your sockets? I am not a heavy node.js user, but I think:

var conn = new net.Socket();
conn.destroy(); //Are you doing this?

To address point 2: Set the hard and soft open file limit to something high enough to stay out of your way:

launchctl limit maxfiles 8192 8192

Running sudo launchctl limit with no arguments should print out your current limits. Check out the Apple documentation for launchctl for more details.