5 ms·
His primary use case is different for mongrel2 compared to mongrel however its based off the same HTTP parser and is a webserver so I guess the continuation see
by chuhnk 16y ago
His primary use case is different for mongrel2 compared to mongrel however its based off the same HTTP parser and is a webserver so I guess the continuation seemed appropriate. Being completely written in C its going to be blindingly fast. I have a feeling it'll surge past unicorn, thin, passenger and everything else out there once its refactored and past beta.
- icey 16y agoDon't you think AGPL licensing will slow adoption? Nobody seems to be able to clearly define what you have to open source if you use AGPL'ed code.
- mark_l_watson 16y agoI think that you simply need to buy an alternative license. This is also the way neo4j is monetized.
- stesch 16y agoAFIK you just have to publish the source to the changes you made to mongrel2 itself if your server is public. And mongrel2 is not embedded. You connect to it. No linking. It's a server.
- cmelbye 16y agoUnicorn, Thin, and Passenger are all mainly written with C/C++ as far as I know.
- chuhnk 16y agoUnicorn and thin are both written in ruby with the core being the ragel HTTP parser which was first implemented in mongrel. Thin took that ragel parser and added eventmachine to the mix which made it much faster the mongrel. Unicorn went a step further by leveraging the kernel in such a way that things got even faster. Macournoyer, creator of thin was working on thin-turbo, a rewrite of the thin backend in C but stopped a while back. Passenger I guess because its nginx or apache module has to be C but their focus was never performance, more ease of deployment. Passenger 3 will have performance improvements and they've got benchmarks here http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-technology-preview-1-performance-2/ http://blog.phusion.nl/2010/06/10/the-road-to-passenger-3-te... but I'm thinking mongrel2 will one up it.
- davidw 16y agoThe advantage of Passenger is that it takes care of dynamically allocating instances of your app, adding them and removing them as needs be. I don't think Mongrel ever did this: you had to guess at how many instances you might need and hope for the best. (At least afaik - no one has ever corrected me when I've said that in the past).
- uxp 16y agoYou're correct, Mongrel had predetermined number of instances.
- zedshaw 16y agoI actually wouldn't compete with those servers, because they are very language specific. I'm aiming for Mongrel2 to unify all the languages in the network architecture so that you can do what companies actually do: use what works. I could easily see Passenger or others providing a 0mq connector that Mongrel2 can talk to. Passenger is bad ass at running Ruby, so no point in trying to do that better.
- jfager 16y agoI'm not a Ruby guy, so this might be a stupid question, but: why would you need to run more than a single instance of an app on a given server?
- grandalf 16y agoThat just refers to running multiple processes instead of multiple threads. Rails wasn't thread safe until recently and many ruby libraries still aren't (including the mysql driver). So it's common practice to run a "pack of mongrels" (a few processes simultaneously) and then load balance between them in case a long request ties one up for a while. Mongrel2 will let you effectively design part of your app to benefit from Rails (for example) and part to use 0mq and do a more evented style of design. All within one configuration / approach.
- sandofsky 16y agoRuby 1.8 uses green threads, so running multiple processes lets you use all your cores. As mentioned in another post, Rails used to not be thread safe. Right now I'm running a Rails site in production with multithreading enabled, but I'm sure many libraries in Ruby are not thread safe.