On May 7, 2:06 am, Jonathan Vanasco <jonat...@findmeon.com> wrote:
> I'm of this school of thought:
>
> if you're doing anything with moderate to high traffic, you should be
> running NGINX on port 80 , with a proxypass to something else.
>
> What you proxypass to, however, is up to you.
> 1- paster
> 2- wsgi
> 3- apache
>
> the important thing is to get Apache off of port 80 , its really just
> not a great performer.
>
> you *especially* don't want to run apache on port 80 if you're using a
> single apache configuration.  the mod_perl folks did the math and
> wrote a chapter or two about it, which may have wound up online... it
> was called "vanilla apache + mod perl" or something like that.

Comparing to mod_perl is not a good idea as they only support
embedding. That is, the Perl application resides in the actual Apache
server child processes. Thus the excessive requirements of a fat Perl
application affected overall Apache memory usage and performance.

The same is the case for mod_python and embedded mode of mod_wsgi. You
can see how some of this plays out for Python in:

  http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

If you use daemon mode of mod_wsgi, which uses distinct processes like
fastcgi/scgi/ajp solutions, you avoid those issues.

So, as long as you ensure out of process solution used such as
mod_wsgi daemon mode, fastcgi or scgi etc, Apache as front end is
going to be more than adequate for the majority of people.

Even so, still agree that nginx front end does bring some benefits in
respect to static file serving and isolation of Apache from slow
clients, thereby allowing Apache to perform better with less resources
than would be required if used as front end.

Graham

> you basically want the lightest and leanest server running on port 80
> as possible (nginx, or a stripped down apache with as few DSOs loaded
> as possible) .  you can then proxy back to other servers as needed.
> if you decided to stay apache, you DEFINITELY want to run a vanilla
> instance on port80 to handle static files and proxy back.
>
> the reasons for this are twofold:
> 1- IIRC, a stripped down apache process is 500k or so of memory; a
> mod_* will grow to 3-5MB, and then compile in your application code
> and allocated/reserved memory... which often ends up at 20-30MB per
> process.  if you run your app on port 80, both static files and
> dynamic content will be served by these apache processes - which means
> you'll tie up the 20-30mb processes with tasks a 500k one could do.
> if you profile your app correctly, you can find the right types of
> servers to run that will easily allow you to increase your throughput
> by 10-20x -- if not more -- just by smarter resource allocation.
>
> 2- if a client is slow, or drops a connection without being detected,
> your dynamic apache ( or anything else ) just sits there sloooowly
> serving a file until a timeout is reached.  if you put a 'vanilla'
> server on port 80, the dynamic server instantly returns the result to
> it... and it can handle the timeout/slowdown issues... freeing up the
> memory and processor for the dynamic server to process another
> request.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-disc...@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/pylons-discuss?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to