Sails Cluster / Auto Reload

![screen shot 2014-05-17 at 3 51 47 pm](https://cloud.githubusercontent.com/assets/1413330/3005944/bb1ea174-ddfc-11e3-8703-b7abe4db9f1c.png)
Attempting to address the *auto reloading* feature in development environment with cluster processes. 

It also allows sails to run with a cluster of processes.


Approach
-------
The master proc bootstraps the app and starts grunt task, but stops before actually starting the http server. It then forks n workers in start.js which all listen and share the app's port using node's very own [cluster](http://nodejs.org/api/cluster.html). Worker processes are delegated the server.listen() and the worker count can be set in `--workers n` or in `sails.config.workers`.

In the development environment, the master proc will also watch the ./api file tree and on change-like events, cycle the cluster of workers with a kill signal. Didn't see a need to gracefully restart workers since cycling the workers is a development-only task.

In the event that a worker dies, another is immediately forked in its place. You can test this by sending a `kill` through your terminal to one of the forks. It will replace itself.

Re-forking processes that die will also occur in `production` environment. Ensuring that they are cycled in a long-running application.

There's a monkey patch for npm cluster in start.js addressing the missing port attribute on server(). It's not yet been addressed in node, but with the provided patch, the tests and servers all run correctly. (the server runs correctly without it, but attempts to check `address().port` throw exceptions).

I've screenshot some preliminary benchmarking on concurrency and request timing with siege and results can be seen below. 

I'm sure I've missed some issues, but all tests pass and I'd be glad to work through whatever issues arise as well as strategize how to write better/more tests for this.

![screen shot 2014-05-18 at 11 09 36 pm](https://cloud.githubusercontent.com/assets/1413330/3009660/16a4724c-df03-11e3-909b-69c3099db25b.png)


Todo
-----
+ Include warnings about too many workers.
+ Give workers a time to live and cycle them for freshness.
+ Test performance / connectivity with regards to database requests.
+ Gracefully cycle workers (if there's a need?)


Benchmarks
------

500 concurrent connections, 1 process
![screen shot 2014-05-18 at 10 23 30 pm](https://cloud.githubusercontent.com/assets/1413330/3009511/d394892a-defc-11e3-83c1-1ff6554ded69.png)

500 concurrent connections, 10 workers
![screen shot 2014-05-18 at 10 21 39 pm](https://cloud.githubusercontent.com/assets/1413330/3009515/e1c51884-defc-11e3-97a6-9f38554fe733.png)

======

300 concurrent connections, 1 process (master)
![300 concurrent connections](https://cloud.githubusercontent.com/assets/1413330/3005938/813d5ed2-ddfc-11e3-8ef5-2f50da5489c7.png)

300 concurrent connections, 8 workers (master)
![300 concurrent connections](https://cloud.githubusercontent.com/assets/1413330/3005936/813bcd42-ddfc-11e3-9994-d84b03d8a34d.png)


======


1000 concurrent connections, 1 process (master)
![1000 concurrent connections](https://cloud.githubusercontent.com/assets/1413330/3005937/813d1968-ddfc-11e3-8653-26a729f218b9.png)


1000 concurrent connections, 8 workers (sails-cluster)
![1000 concurrent connections](https://cloud.githubusercontent.com/assets/1413330/3005939/813d7750-ddfc-11e3-87c4-839d7091aaa5.png)