On Wed, 2009-07-22 at 04:47 -0700, Graham Dumpleton wrote: > > > On Jul 22, 9:34 pm, Le Roux Bodenstein <lero...@gmail.com> wrote: > > > If it is to bring down application for maintenance, seems like it > > > would be easier to use Apache/mod_wsgi in daemon mode. > > > > I'll give mod_wsgi a go. To be honest I never looked at it before > > simply because it is tied to apache. But if it can easily do > > everything I need using a reasonable amount of memory and provide > > decent performance, then I'll allow it ;) > > > > My app pre-dates mod_wsgi and at the time mod_python just seemed too > > bloated. > > There is a lot of myth to that. Although older versions of mod_python > had some memory leaks, that has in the main been addressed. The > problems with memory bloat were Python installations with no shared > library for Python and bad configuration of Apache. For a bit of a > discussion see: > > http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html > > > I've never been an apache fan and memory usage is/was my main > > concern which is why I leaned towards lighttpd. At the time I felt > > that it performed better with serving up static files, but I haven't > > actually benchmarked it in ages. I suppose you can run lighttpd/nginx > > in front of apache, > > And I would also suggest you run nginx in front. It is good at static > file serving and also because of the way it handles proxying, isolates > Apache from slow clients. This means that Apache is being used for as > little time as possible as nginx will act as a buffer and handle the > talking to the slow client. You therefore get optimal use of Apache > resources, much better than if Apache was the front facing web server > and was handling both static and dynamic requests. Behind nginx, > Apache doesn't have to worry about keep alive either. > > > but all apache is really doing by then is act as a > > proxy that converts http into something mod_wsgi daemons understand > > which just feels terribly bloated to me.. > > How much memory a Python application takes up is not really going to > vary whatever mechanism you use. So, if you run a multiprocess > configuration with 5 process, be it with mod_wsgi daemon mode, flup or > mod_proxy load balanced, that is still 5 times whatever amount of > memory your application requires. There is nothing about Apache that > suddenly means your application needs twice as much memory or > otherwise bloats out more than it would with other mechanisms. There > is a lot of FUD and misunderstanding around using Python with Apache, > it is not as evil as some would like to portray, you just need to > configure it properly and understand how it works to make best use of > it. > > Overall, the only difference should be the minimal amount of memory > Apache itself adds to each process, but in the context of your typical > fat Python web application that is small enough to be neglible. > > Graham
I probably wouldn't have replied to this, but it riled me with the implication that apache cannot serve dynamic content and static content efficiently (maybe you didn't mean that, and I'm getting the wrong end of the stick, this happens to be my pet peeve!). Just as there is plenty of FUD around using python with apache, there is just as much surrounding apache, with people suggesting nginx, lighty etc as 'solutions'. Our solution is simple; configure apache correctly for your needs, and it behaves correctly in all scenarios. First off, we use the event MPM for apache. This is a threaded MPM that uses event queues for various parts of the request processing, and is extremely efficient. Secondly, and just as important, read your config file, understand each directive and decide if YOU need it on YOUR site. If you don't use apache's content negotiation, then don't load mod_negotation. The downside of the event MPM is that it is threaded, so throw out any mod_<lang> modules, even if the core is thread safe, it only takes one extension that is not to bork your server. For example, django is purported to be thread safe, but there are many python libraries that are not. Instead, we run each dynamic application separately, as a fastcgi or wsgi application. This gives you the benefit of tuning the number of worker processes by application, and allows you to use your OS to control resources for the application. We run all of ours as fastcgi instances, as that is language neutral, and allows us to run any webapp in the same manner. Since we are running the event MPM, apache scales efficiently to handle large volumes of requests. Apache directly serves any static content, and it is efficient to use an apache worker thread to do this, rather than insert something like nginx in front of it. Dynamic requests are handled by mod_fastcgi, and (in our usual setup) the apps that actually end up handling the request run on different boxes. All in all, our single httpd server handles between 3-8 million requests per day, its load average fluctuates between 0.00 and 0.05. The apache instances (usually 4, maximum 10) use about 12 MB for each instance. Cheers Tom --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
