Matt Smith <matthewcalebsmith at 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