Re: Unicorn vs Apache

[Eric Wong <normalperson@yhbt.net>]

Matt Smith <matthewcalebsmith@gmail.com> wrote:
> Hello all,
> 
> I have always deploys rails apps with unicorn and nginx as a reverse
> proxy in the past. However, I am working with a new firm and they would
> like to use Apache with mod_pagespeed in front of unicorn.
> 
> We will be deploying a rails 3.1 app with streaming. To me,
> mod_pagespeed does not seem like a magic bullet, as it appears to be a
> collection of best practices which have to be rewritten as a page is
> being served.

note: mod_pagespeed is totally independent if Rails 3.1 streaming.

Keep in mind the most important feature of nginx Unicorn relies on (full
request/response buffering) also defeats Rails 3.1 streaming because of
how it's currently implemented.

> Why not code with the best practices in mind as to not
> have to scan and yet again reprocess the content?

My thoughts exactly :)  But implementing those best practices
isn't cheap, either.  If you have to run mod_pagespeed, the safest
configuration would be:

  nginx <-> mod_pagespeed <-> unicorn

Of course that would introduce latency.  Maybe there's Rack middleware
that works like mod_pagespeed...

> Searching on the web, I find few entries about mod_page speed and rails,
> and relatively few entries about apache with unicorn.

Apache + Unicorn is still unsupported since (as far as anybody knows),
it doesn't fully buffer responses and requests to completely isolate
Unicorn from the harmful effects of slow clients.

> To me it seems that using best practices, with appropriate use of
> caching, and nginx would be a better solution than apache with
> mod_pagespeed.

I agree.

> Questions:
> 
> 1) Does nginx provide any necessary services to unicorn, that apache
> cannot provide?

nginx provides full request + response buffering (all uploads, and large
response bodies that can't fit into socket buffers).  nginx also
provides inexpensive handling of idle keepalive connections; so you
can have a lot of idle connections for little memory usage.

Apache 2.x mpm_event /should/ be as good *if* (and only if) it an
provide the full request/response buffering; but I don't have any
experience with it.  mpm_worker can be fairly efficient with Linux+NPTL
if you can use smaller pthreads stack sizes (and are using 64-bit).

> 2) If apache can provide all necessary services, does it do them as well
> as nginx.

Buffering + keepalive maintenance is the most important thing I care
about, and as far as I know, Apache doesn't do that as well as nginx.

> 3) We would like the fastest user experience possible. Does apache with
> mod_pagespeed hold any weight here over nginx?

The full request/response buffering of nginx also hurts latency a
little, so the user experience is slightly worse under low load.
However, nginx does the best job of keeping things going under high
load.

> 4) Part of a fast user experience is how fast you get the page, correct?
> Seems like nginx has the upper hand here, due to nginx's nio vs apache's
> threading.

Not sure what "nio" means... non-blocking I/O?  Apache can use mpm_event
which is like the non-blocking + event loop nginx uses, but AFAIK the
buffering of requests responses is not like what nginx implements.

> 5) Would it make since to put nginx in front of apache w/mod_pagespeed
> (or visa versa), to use the applicable mod_pagespeed filters? Or is this
> a bad idea to begin with?

nginx <-> mod_pagespeed <-> unicorn should be alright, but of course not
ideal because of the extra copying + latency involved.

For non-Ruby/Rack apps, I've always recommended nginx sit in front of
any Apache 1.3 or 2.x+mpm_prefork apps that are exposed to slow clients,
too.

> 6) Is there anything else I am missing? Are there any specific resources
> I need to look at?

If you're willing to take a risk with Rainbows!, I posted some notes
about making it work with Rails 3.1 streaming here:

http://thread.gmane.org/gmane.comp.lang.ruby.rainbows.general/229

Keep in mind nobody I know of uses Rainbows! in production; but
it /should/ be able to work without nginx (or any proxy).

> 7) Should we go with nginx or apache? (Opinions ok.)

nginx remains the only supported reverse proxy for Unicorn at this
moment.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying