

Phusion Passenger now supports Nginx - _pius
http://blog.phusion.nl/2009/04/16/phusions-one-year-anniversary-gift-phusion-passenger-220/

======
_pius
It would be difficult to overstate how major this is for the Ruby web app
community.

~~~
fiaz
Especially given the fact that all of those MagLev claims went up in smoke...

~~~
gnaritas
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.

~~~
jules
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?

~~~
gnaritas
> 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.

------
phoreo
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.

------
tlrobinson
Little known fact: Passenger also supports Python WSGI
applications/frameworks. Perhaps it will become the de facto replacement for
FastCGI.

------
zacharypinter
Aside from supporting an existing infrastructure, what are the benefits of
choosing Nginx/Passenger over Apache/Passenger in a fresh environment?

~~~
Xichekolas
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.

~~~
rcoder
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.

------
dmix
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.

~~~
gamache
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.

------
billturner
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...

~~~
listic
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 :)

------
datums
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.

------
dmillar
Well, do I stop working on my Passenger-like Nginx module that uses thin?

~~~
grandalf
I'd be interested in it -- i love having EM running in the web server...

~~~
FooBarWidget
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.

------
jzting
nice! has anyone done any benchmarks yet?

~~~
davidw
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.

~~~
rcoder
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.

------
ruby_roo
Phuckin' sweet. I love these guys!

------
sho
Well, there goes the last reason to bother with mongrels + monit. There was a
discussion here a week or two ago where someone was asking about best Rails
deployment - the recommendations pretty much came down to Passenger + Apache
for ease, or Nginx + mongrels for speed / low memory use.

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.

