4 ms·

From the FAQ: http://postrank-labs.github.com/goliath/doc/index.html http://postrank-labs.github.com/goliath/doc/index.html How do I deploy Goliath in prod

From the FAQ: http://postrank-labs.github.com/goliath/doc/index.html http://postrank-labs.github.com/goliath/doc/index.html How do I deploy Goliath in production? * We recommend deploying Goliath behind a reverse proxy such as HAProxy, Nginx or equivalent. Using one of the above, you can easily run multiple instances of the same application and load balance between then within the reverse proxy. I am still wondering about how Goliath fits into both deployment architecture and application development. Traditionally these 2 have always been separated out. * Thread safety. It is explicitly mentioned that middleware used must be thread safe. Doesn't this hold for all code? * Can Goliath use multiple cores, or does one instance need to be spun up for each core? * does it make sense to say, server a Sinatra app from Goliath?

getsat 16y ago
> I am still wondering about how Goliath fits into both deployment architecture Probably in a manner not entirely dissimilar to Unicorn: https://github.com/blog/517-unicorn https://github.com/blog/517-unicorn I generally do 2x the number of cores (e.g., eight Unicorn workers on a quadcore box), but it depends on your application. A heavyweight application with 150 models and lots of cpu-intensive tasks will suffer more from context switches than a lightweight one which spends most of its time idle.
igrigorik 16y ago
In all cases where we've deployed goliath, its running with a single thread. In theory, nothing stops you from creating a thread to do some background task (or EM.defer), but then you're on your own to make sure you have all the right synchronization logic. As far as middleware goes, because you are reusing the same "app chain" between multiple requests, you just have to make sure that your middleware does not rely on any instance variables since those will get clobbered by other requests. Check the wiki page on middleware, we have a few examples around this. Last but not least.. the EM reactor runs on a single core, so you're basically in the same deployment scenario as Thin or node.js. Having said that (always a caveat! ;)), Goliath can run on JRuby and Rubinius.. so in theory we have non-GILed environments there, which means we can start multiple reactors and run across multiple cores from within the same proc. This is not something I've experimented with in practice yet, but in theory its possible.
- astrodust 16y ago
  2011 is either going to suck or be awesome depending on how quickly the new Ruby 1.9 features are taken up by Rubinius and JRuby. Having to choose between multiple threads and a better language is really not a decision you should have to make.
  - igrigorik 16y ago
    --1.9 mode works really well under JRuby now - that was a big push within 1.6 and they've made a lot of progress. I'd call it "almost there". Rubinius is a little bit further behind, but I've been able to run our Goliath stack on it, and that exercises quiet a few syntactic changes. So, I think both are close.

getsat 16y ago

> I am still wondering about how Goliath fits into both deployment architecture Probably in a manner not entirely dissimilar to Unicorn: https://github.com/blog/517-unicorn https://github.com/blog/517-unicorn I generally do 2x the number of cores (e.g., eight Unicorn workers on a quadcore box), but it depends on your application. A heavyweight application with 150 models and lots of cpu-intensive tasks will suffer more from context switches than a lightweight one which spends most of its time idle.

igrigorik 16y ago

In all cases where we've deployed goliath, its running with a single thread. In theory, nothing stops you from creating a thread to do some background task (or EM.defer), but then you're on your own to make sure you have all the right synchronization logic. As far as middleware goes, because you are reusing the same "app chain" between multiple requests, you just have to make sure that your middleware does not rely on any instance variables since those will get clobbered by other requests. Check the wiki page on middleware, we have a few examples around this. Last but not least.. the EM reactor runs on a single core, so you're basically in the same deployment scenario as Thin or node.js. Having said that (always a caveat! ;)), Goliath can run on JRuby and Rubinius.. so in theory we have non-GILed environments there, which means we can start multiple reactors and run across multiple cores from within the same proc. This is not something I've experimented with in practice yet, but in theory its possible.

astrodust 16y ago
2011 is either going to suck or be awesome depending on how quickly the new Ruby 1.9 features are taken up by Rubinius and JRuby. Having to choose between multiple threads and a better language is really not a decision you should have to make.
- igrigorik 16y ago
  --1.9 mode works really well under JRuby now - that was a big push within 1.6 and they've made a lot of progress. I'd call it "almost there". Rubinius is a little bit further behind, but I've been able to run our Goliath stack on it, and that exercises quiet a few syntactic changes. So, I think both are close.