Thanks. One interesting idea is Node.JS clustering, which is a way of spawning multiple services on the same node, sharing a port, to take advantage of multi core servers.
- nodejs.org/api/cluster.html Beyond that, just putting a reverse proxy in front of a cluster of servers seems to be the accepted pattern, so we can do that in Brooklyn easily enough. Andrew. -- -- andrew kennedy ? cloudsoft & software engineer : @grkvlt ; On 25 Aug 2014 10:33, "Richard Downer" <[email protected]> wrote: > On 24 August 2014 20:43, Andrew Kennedy > <[email protected]> wrote: > > I've recently merged the code for a new entity that runs a Node.JS > > application from a GitHub repository or a .tgz archive > [..] > > One really cool thing about this is that you can build a complex > > multi-service application that uses Node.JS using only the YAML > blueprint. > > That is very cool - a complete app defined using off-the-shelf > components and references to existing code, deployed to a cloud (or > Docker-Clocker) just using YAML and no additional coding. Just what > Brooklyn should be about :-) > > I'm not hugely familiar with Node.js. I'm assuming it's using its own > embedded web server - are there any interesting sensors we can get out > of that to drive an auto-scaler policy? But then Node's reputation is > that it can already reach a very high throughput compared to its > competition so maybe scale is not an issue :-) > > Richard. >
