Phusion Passenger now supports Nginx(blog.phusion.nl)
blog.phusion.nl
Phusion Passenger now supports Nginx
http://blog.phusion.nl/2009/04/16/phusions-one-year-anniversary-gift-phusion-passenger-220/
36 comments
It would be difficult to overstate how major this is for the Ruby web app community.
Especially given the fact that all of those MagLev claims went up in smoke...
MagLev is a Gemstone object database server, it has nothing to do with this. When it's done, I'm sure the combo will be Nginx + Maglev instead of Nginx + (phusion passenger + mysql).
I've been playing with Gemstone and Seaside lately, it's freaking blazing fast and persistence is automatic, no mapping code at all. You put objects somewhere and they just stay there. No mapping at all beats the crap out of mappings + migrations.
Gemstone is going to make one hell of a web app platform. Especially since you can just add more boxes to the db cluster for scaling it. Only one server can write, but reads are distributed automatically across all servers in the cluster.
I've been playing with Gemstone and Seaside lately, it's freaking blazing fast and persistence is automatic, no mapping code at all. You put objects somewhere and they just stay there. No mapping at all beats the crap out of mappings + migrations.
Gemstone is going to make one hell of a web app platform. Especially since you can just add more boxes to the db cluster for scaling it. Only one server can write, but reads are distributed automatically across all servers in the cluster.
How do they make Gemstone so fast? They have to track every assignment to every persistent object, right? How does Gemstone handle data that doesn't fit in memory?
> How do they make Gemstone so fast?
Gemstone is like a smart memcached + relational db. They call it a shared page cache, but it's basically like memcached but not just a cache and with brains.
A transaction commits through the cache to disk and the same object format is used by every layer removing the need to constantly re-serialize. The client talks to the cache, the cache talks to the back end store when it decides it needs to page something in.
As for change tracking, I'm fairly certain there's a write barrier at the vm level, change anything and the barrier is broken causing the object to added to a commit list.
As for larger than memory queries, no different than a relational store, you work in batches paging in data as necessary. If you're talking about a single transaction that modifies more than will fit in ram, I have no idea, I've never had to do something like that.
Gemstone is like a smart memcached + relational db. They call it a shared page cache, but it's basically like memcached but not just a cache and with brains.
A transaction commits through the cache to disk and the same object format is used by every layer removing the need to constantly re-serialize. The client talks to the cache, the cache talks to the back end store when it decides it needs to page something in.
As for change tracking, I'm fairly certain there's a write barrier at the vm level, change anything and the barrier is broken causing the object to added to a commit list.
As for larger than memory queries, no different than a relational store, you work in batches paging in data as necessary. If you're talking about a single transaction that modifies more than will fit in ram, I have no idea, I've never had to do something like that.
There still is (and needs) the concept of migrations in Gemstone.
Not necessarily. You can migrate old instances of a class to the new version of a class, but unlike a relational database, you don't have to. Unlike a relational db, an object db allows storage of many different versions of the same class to be stored. It's up to the application to decided if it needs a particular version to run.
You could for example add a new instance variable and change the way something is calculated and as long as the public interface of the class doesn't change you don't have to migrate the old instances; the new calculation could apply from this date forward.
You could for example add a new instance variable and change the way something is calculated and as long as the public interface of the class doesn't change you don't have to migrate the old instances; the new calculation could apply from this date forward.
I know. What you say reinforces my point. There is (and it needs) to have the conception of migration. Nothing wrong. It is a necessity.
But it is an important point, because DB migration is always around, not something that happens magically.
But it is an important point, because DB migration is always around, not something that happens magically.
I don't understand what this has to do with MagLev. (And how did it go up in smoke? According to this http://maglev.gemstone.com/status/index.html it seems like it's still being worked on.)
The point I was trying to make is that performance is the biggest issue with Ruby, and that is a hard issue to deny. MagLev was introduced with the promise of delivering this much needed performance.
In relation to the comment to which I responded, I think it is a big boost to the Ruby community (especially the Rails community) that Passenger and Nginx are playing nicely with each other.
Perhaps I shouldn't have been so bombastic in my statement that the MagLev claims have "gone up in smoke"...that's just my response to the fact that they have demonstrated some pretty amazing stuff but are a little short on delivery.
To be clear Phusion's release today not only promises on a performance boost for Rails, but it also delivers it.
Everybody is 100% right in pointing out that technically speaking, MagLev and Passenger/Nginx are totally separate technologies to solve separate problems, but the goals are the same in my view (delivering better performance for Ruby apps). So I don't think drawing an allusion to the MagLev promises of increased performance for Ruby is unwarranted in relation to what it would mean to the Ruby community at large.
In relation to the comment to which I responded, I think it is a big boost to the Ruby community (especially the Rails community) that Passenger and Nginx are playing nicely with each other.
Perhaps I shouldn't have been so bombastic in my statement that the MagLev claims have "gone up in smoke"...that's just my response to the fact that they have demonstrated some pretty amazing stuff but are a little short on delivery.
To be clear Phusion's release today not only promises on a performance boost for Rails, but it also delivers it.
Everybody is 100% right in pointing out that technically speaking, MagLev and Passenger/Nginx are totally separate technologies to solve separate problems, but the goals are the same in my view (delivering better performance for Ruby apps). So I don't think drawing an allusion to the MagLev promises of increased performance for Ruby is unwarranted in relation to what it would mean to the Ruby community at large.
For me, the big win of Passenger is freeing myself from manual administration of Rails apps. Any performance gain is secondary to the fact that I can drink beer while I rest assured my apps are being served.
I totally agree with this sentiment...actually I've already decided to use Apache/Passenger for an app I'm releasing (hopefully soon for all to review). Today's announcement is really icing on the cake.
My reasoning prior to today's announcement? The convenience of the deploy. The fact that I don't have to dive into Ebb/Thin/Mongrel and figure that out (probably easy for 99% of the people on this thread) means more time to think about other things.
It's also exciting from the perspective that I'm interested in seeing what the Ebb/Thin/Mongrel teams are going to do. Competition is great!
My reasoning prior to today's announcement? The convenience of the deploy. The fact that I don't have to dive into Ebb/Thin/Mongrel and figure that out (probably easy for 99% of the people on this thread) means more time to think about other things.
It's also exciting from the perspective that I'm interested in seeing what the Ebb/Thin/Mongrel teams are going to do. Competition is great!
I'm with you man -- I consider myself a pretty good coder, but I'm a really crummy sysadmin. Trying to figure out how to configure Mongrel correctly has always been the worst part of Rails development for me, so Passenger is a welcome relief.
I didn't think you were being bombastic; I just don't keep up to date with the goings-on of Ruby, so I thought I might have missed something.
I do think it may be a bit premature to call MagLev vaporware though; it was only announced last year, no?
Anyways, thank you for following up, it did help illustrate your point for me.
I do think it may be a bit premature to call MagLev vaporware though; it was only announced last year, no?
Anyways, thank you for following up, it did help illustrate your point for me.
I see it as related in a vaporware vs nonvaporware context. Rubyists have put up with quite a bit of vaporware lately, so it's remarkable that Phusion continue to deliver with Passenger without blowing smoke. (I'd also put JRuby in this small bucket.)
Isn't that too early to conclude? And they are meant for different purposes anyway.
This is great to see. I've been curious about trying Passenger, but am addicted to Nginx. Looking forward to playing around, and if the fit is right, deploying with it.
Little known fact: Passenger also supports Python WSGI applications/frameworks. Perhaps it will become the de facto replacement for FastCGI.
Aside from supporting an existing infrastructure, what are the benefits of choosing Nginx/Passenger over Apache/Passenger in a fresh environment?
Biggest advantage off the top of my head is memory usage (which matters when you are on a memory constrained VPS like a 256 slice). Nginx memory usage stays low under lots of load, since it has a constant number of workers and a job queue. I'm not clear on how exactly Apache does it, but my understanding is that it forks a child process to service each request, so under high loads gobbles up memory.
Second graph here illustrates: http://blog.webfaction.com/a-little-holiday-present
Personally, I also find Nginx more straightforward to configure, but I know that is mostly personal preference.
As an aside: I really love Engine Yard for sponsoring the development of this.
Second graph here illustrates: http://blog.webfaction.com/a-little-holiday-present
Personally, I also find Nginx more straightforward to configure, but I know that is mostly personal preference.
As an aside: I really love Engine Yard for sponsoring the development of this.
Using a default configuration, Apache actually maintains a pool of worker child processes which handle the actual request processing, rather than forking on every incoming request. You can allow it to fork more workers under load, or keep it locked down to manage resource usage. You can also configure it to use an alternate MPM (Multi-Processing Module) to use thread pools, fork on each request, or some mix of the above.
The difference in resource usage is due more to the fact that Apache is written to be a sort of generic network service platform, rather than a lean-and-mean HTTP server. It allows plug-in modules (whether written in C, or any of the mod_perl/python/ruby/etc. dynamic language bindings) to interact with just about any stage of request processing. In addition, a default Apache install will usually link a large number of other modules in each worker
That being said, tuning Apache for performance + minimal resource usage is a bit of a black art. If you're not comfortable configuring + building your own server package from source, it's probably easier to just grab Nginx and be done with it.
The difference in resource usage is due more to the fact that Apache is written to be a sort of generic network service platform, rather than a lean-and-mean HTTP server. It allows plug-in modules (whether written in C, or any of the mod_perl/python/ruby/etc. dynamic language bindings) to interact with just about any stage of request processing. In addition, a default Apache install will usually link a large number of other modules in each worker
That being said, tuning Apache for performance + minimal resource usage is a bit of a black art. If you're not comfortable configuring + building your own server package from source, it's probably easier to just grab Nginx and be done with it.
Apache isn't that great for serving static content; I've read about plenty of people who use Nginx for static and Apache for dynamic. Now you can use Nginx for everything.
Finally. I was wary of moving back to apache to use Passenger because I had nginx configured to work perfectly with my app. Now its just a matter replacing mongrel.
I was wary too... then in the space of about ten minutes, I had Apache and Passenger set up and I never had to worry about babysitting my Rails apps again.
I can't wait to try Passenger on Nginx.
I can't wait to try Passenger on Nginx.
And just TWO days ago, I switched two big apps running nginx + thin to running apache + passenger - mainly for the ease of maintenance. If I had only waited two days...
I hope you've got meaningful experience. Now switching back should be easier.
You know, they say the best way to do something right is to do it twice :)
I've been working with nginx (haproxy to mongrel) and recently nginx to (apache phusion) , this is the ideal marriage. Awesome news, glad I donated.
Well, do I stop working on my Passenger-like Nginx module that uses thin?
Not if it's not sucking up giant amounts of your time (and if you're enjoying working on it). People will still be interested. Just perhaps not as many ;-)
I'd be interested in it -- i love having EM running in the web server...
The reason why EventMachine doesn't work in Phusion Passenger is probably because of forking. You can use the :starting_worker_process event in Phusion Passenger to reinitialize EM after forking (see the docs on spawn methods) or use conservative spawning.
nice! has anyone done any benchmarks yet?
I'd be willing to bet good money that benchmarks are still going to hinge on the speed of your Ruby app and its database access. Apache, despite not being the "new, new thing" is perfectly capable of saturating pretty much whatever connection you have.
This is something I keep trying to tell people whenever micro-benchmarks appear showing that such-and-such web server handles >5k concurrent connections within a particular memory footprint, or that this-and-that message queue supports 8k enqueue/dequeue ops per second without hitting disk.
How many Rails apps out there can handle more than, say, 200-300 concurrent clients without either pegging the CPU or bringing the database to its knees?
Putting Passenger behind Nginx just removes a need to install + configure Apache for folks who are already use and like Nginx. It may also have some benefit on memory-constrained environments like entry-level VPS hosts.
That being said, I personally think that folks who spend days or weeks tweaking their deployment to run in <256MB of RAM to save a few bucks a month on hosting should probably reevaluate their priorities.
How many Rails apps out there can handle more than, say, 200-300 concurrent clients without either pegging the CPU or bringing the database to its knees?
Putting Passenger behind Nginx just removes a need to install + configure Apache for folks who are already use and like Nginx. It may also have some benefit on memory-constrained environments like entry-level VPS hosts.
That being said, I personally think that folks who spend days or weeks tweaking their deployment to run in <256MB of RAM to save a few bucks a month on hosting should probably reevaluate their priorities.
Phuckin' sweet. I love these guys!
This is the best of both worlds and pretty much puts Passenger at the top of any deployment best practise list. Well done to them.