Is Socket.IO open connections?

Question

I am currently working with DerbyJS because it contributes to cleaning up EXISTING client / server code. Lateral advantage (the main reason why most people use the framework) uses Socket.IO to create applications in real time. In this case, I do not need in real time, but this is a nice addition.

My question is: can I sacrifice scalability / performance with Socket.IO and all open connections that it supports? Will using Backbone + ExpressJS free up resources since there are no open connections?

Answer 1

Keeping empty open connections obviously has some cost in terms of server overhead, but I wouldn’t worry about such problems if you don’t have an obvious scaling problem. If you have an obvious scaling problem, you should have enough revenue to buy more server resources. Servers are very cheap and your time is very expensive. Don't worry about optimizing the little things.

Answer 2

Am I sacrificing scalability / performance using Socket.IO and all these open connections that it supports?

If you want to refresh your page (dynamic page) immediately when new information is available. Then maintaining the connection using a non-blocking io is the most effective way to do this. Fortunately, node.js uses a non-blocking io. This is one of the reasons node.js is so popular (plus that you can code in JavaScript, which is the most popular programming language). If you really don’t need it (also in the future), because your site is quite static (not in real time, as you said), then closing the connection will save your resources.

Will using Backbone + ExpressJS free up resources since there are no open connections?

I would look at the cost (development time) for developing your site using a basic / express combination compared to derbyjs.

Then again, like Nate , it is mentioned that Socket.io can handle many (1000+) concurrent connections. If it is easier to develop with derbyJS, I would use it. When you cross this road, you can always decide to add more servers or redesign (hire additional programmers) on your website to use a combination of express memory. First, try to get to the point where users find your site valuable with minimal effort (time to develop).

PS: I think you should try to keep your system as modular as possible in order to replace Derby.js with something else with the least amount of time.