Hacker News Reader

Comment by sh1mmer | Hacker News Reader

There are a bunch of factors in scaling up a Node service. Like any other technology memory per user is a factor, in Node this tends to be connection state, and some application state. Node currently has a ~2gb JavaScript limit per process for JavaScript object (not Buffers).

Since Node bounces much work to the kernel then kernel and TCP factors can play a part. So ulimit, and ephemeral port tuning is important.

Finally at some point CPU load for doing keep-alive on open lots of connections has a cost. So that is also a limiting factor.

In general it depends what you are doing. Using Joyent's SmartOS (a Solaris varient) I was able to hold just under a million TCP connections on a single Node process. However the ability to service those Node is extremely limited.

View on HN

Could you please tell a few words about your application, if it is a million connections, it is a million * N database queries on the backend (for a typical web app)?

Would every request still stay in a queue, not on the front-end layer, but on database/storage/messaging/other middleware layer?

I am just wondering what are the benefits of moving a bottleneck one layer up?

Are you not using some sort of caching mechanism? a million queries to a db is probably going to kill it no matter what the front end.

That's why I am wondering what types of applications require so many simultaneous connections. CDNs?

The classical application that comes to mind is a chat app.

Not an application, just a benchmark. There was some keep-alive, and a small amount of state being passed from memory, but nothing heavy. At that level of contention you'll easily saturate a core making the application useless.

My point is more that Node can support a very large amount of connections. Once you scale down to the tens or possibly low hundreds of thousands you can still do real work.

This is mostly useful when you have a server that is looking after a lot of things that don't communicate very often. Sensors is one application for example. While totally passive sensors can poll a server with their data, being able to hold open many very cheap connections allows you ask sensors for their data when the server wants it rather than on an interval. This can cut down the amount of unnecessary data sent a lot.

Would love to know a little about how you're tuning them, I've had unimpressive results both on dedicated + smartos nodejs boxes so far.

When I worked at Joyent I had access to root level params you can't configure on individual SmartMachines by hand. Joyent ops might be able to do it for you, but some of those changes are global per server (affecting all the SmartMachines it hosts).

Reply on news.ycombinator.com