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.
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.
.... / 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.) ....
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:
config/session.js) and install the connect-redis adapter as a dependency of your app (e.g.
npm install [email protected]~3.0.2 --save --save-exact).
npm install [email protected]~1.0.0 --save --save-exact)
productionenvironment, and/or consider turning Grunt off completely. See here for more details on Grunt issues in single-server clusters
config/bootstrap.jscode that persists data in a database, to avoid conflicts when the bootstrap runs multiple times (once per node in the cluster)
Deploying your app to a PaaS like Heroku or Modulus is dead simple. Depending on your situation, there may still be a few devils in the details, but Node support with hosting providers has gotten really good over the last couple of years. Take a look at Hosting for more platform-specific information.
pm2(see http://sailsjs.com/documentation/concepts/deployment for more about daemonology)
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. Specifically 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.
Premature optimization is the root of all evil. -Donald Knuth
No matter what tool you're using, it is important to spend your focus and time on 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 is much easier to do so.
- 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.
- The default Socket.io configuration initially attempts to connect to the server using long-polling. In order for this to work, your server environment must support sticky load-balancing (aka sticky sessions), otherwise the handshake will fail until the connection is upgraded to use Websockets (and only if Websockets are available).
- On Heroku, you must have the sticky load-balancing beta feature explicitly enabled.
- In an environment without stickky load balancing, you will need to set the
transportssetting in config/sockets.js to
['websocket'], forcing it to use websockets only and avoid long-polling. You'll also need to set the transports in your socket client--if you're using
sails.io.js, this is as easy as adding a
<script>io.sails.transports=['websocket']</script>immediately after the
sails.io.jsscript include. For a rather dramatic read on the issue, see this thread.