Question

More of a “best practice” question than a technical one, however I’m trying to figure out the best way of organizing node / express apps to be the most optimized for scaling. Currently we have a single express js application that houses multiple “parts” of a site. This includes areas like chat, our BoxNet api, and a few others.

Would it be better to separate these areas into their own express applications to scale each one individually, or would it be better just to keep them all in one single express application? Talking amongst the different parts of the application is nonexistent as it’s not really necessary. To me, the best reason for separating these applications would be to easily scale one of the different areas without having to scale the parts that aren’t being hit as much. The negative effects I see of this would be a potential management nightmare or multiple connections to a database per application * scale. Thoughts?

Thanks,

Aric

Answer 1

Separating them out can make sense for two reasons:

1. If you have multiple processors on your server, each Node.js app can run its event loop on a separate core and actually run in parallel, rather than appear so, giving you an immediate doubling/tripling of server peformance (assuming not I/O bound).
2. Because all of the logical services are on a single event loop, you’re increasing the frailty of your system. If one service locks up the event loop, all services are locked up. And even if you never have bugs in your various services, you still have the issue that “high-performance” services are penalized by being put into the same event loop.

For instance, suppose you have three services: One is a simple service that spends ~50ms within the Node.js event loop and doesn’t access the DB, files, whatever; it’s all in memory. A second service spends ~100ms within the Node.js event loop and ~400ms waiting on DB/File I/O. A third service spends ~400ms within the Node.js event loop and ~100ms with the DB. Because the event loop is essentially a queue where a logical request is thrown back to the end of the stack each time it waits for non-blocking I/O, your third service could be slowed down by an extra ~300ms for each second service in the queue between it and the front of the queue, and by ~50ms for each first service (after amortizing 2 of these first services).

When all requests to a Node.js server have similar processing and I/O delays, you get a consistent response time to the user, which is better than a randomized response time, since the former means adaptive streaming audio/video will play at a higher bitrate (for example), and a user browsing a web page with a consistent “rhythm” will quickly get into the rhythm themselves and stop perceiving the delays (unless too significant, of course).

Your database should be able to handle dozens of connections at the least simultaneously, so that shouldn’t be a problem; but if the services really don’t talk much to each other, you may want to split the databases into separate processes, as well.