Edit Page

Scaling

If you have the immediate expectation of lots of traffic to your application (or better yet, you already have the traffic), you'll want to set up a scalable architecture that will allow you to add servers as more and more requests hit your app.

Performance

#

In production, Sails performs like any Connect, Express or Socket.io app (example). If you have your own benchmark you'd like to share, please write a blog post or article and tweet @sailsjs. But benchmarks aside, keep in mind that most performance and scalability metrics are application-specific. The actual performance of your app will have a lot more to do with the way you implement your business logic and model calls than it will about the underlying framework you are using.

Example architecture

#
....
                    /  Sails.js server  \      /  Database (e.g. Mongo, Postgres, etc)
Load Balancer  <-->    Sails.js server    <-->    Socket.io message queue (Redis)
                    \  Sails.js server  /      \  Session store (Redis, Mongo, etc.)
                             ....

Preparing your app for a clustered deployment

#

Node.js (and consequently Sails.js) apps scale horizontally. It's a powerful, efficient approach, but it involves a tiny bit of planning. At scale, you'll want to be able to copy your app onto multiple Sails.js servers and throw them behind a load balancer.

One of the big challenges of scaling an application is that these sorts of clustered deployments cannot share memory, since they are on physically different machines. On top of that, there is no guarantee that a user will "stick" with the same server between requests (whether HTTP or sockets), since the load balancer will route each request to the Sails server with the most available resources. The most important thing to remember about scaling a server-side application is that it should be stateless. That means you should be able to deploy the same code to _n_ different servers, expecting any given incoming request handled by any given server, and everything should still work. Luckily, Sails apps come ready for this kind of deployment almost right out of the box. But before deploying your app to multiple servers, there are a few things you need to do:

Deploying a Node/Sails app to a PaaS

#

Deploying your app to a PaaS like Heroku or Modulus is simple! Take a look at Hosting for platform-specific information.

Deploying your own cluster

#

Optimization

#

Optimizing an endpoint in your Node/Sails app is exactly like optimizing an endpoint in any other server-side application; e.g. identifying and manually optimizing slow queries, reducing the number of queries, etc. For Node apps, if you find you have a heavily trafficked endpoint that is eating up CPU, look for synchronous (blocking) model methods, services, or machines that might be getting called over and over again in a loop or recursive dive.

But remember:

Premature optimization is the root of all evil. —Donald Knuth

No matter what tool you're using, it is important to spend your time and energy writing high quality, well documented, readable code. That way, if/when you are forced to optimize a code path in your application, you'll find it much easier to do.

Notes

#
  • You don't have to use Redis for your sessions; you can actually use any Connect or Express-compatible session store. See sails.config.session for more information.
  • Some hosted Redis providers (such as Redis To Go) set a timeout for idle connections. In most cases you’ll want to turn this off to avoid unexpected behavior in your app. Details on how to turn off the timeout vary depending on provider, so you may have to contact their support team.

Is something missing?

If you notice something we've missed or could be improved on, please follow this link and submit a pull request to the sails repo. Once we merge it, the changes will be reflected on the website the next time it is deployed.

Concepts