Tom, it seems to me that you and I are basically in agreement. What you are saying (correct me if I'm wrong) is that apache performs great and is a perfectly good option for django -- so long as you don't rely on stock versions and configurations. What I am proposing is that most django devs do just that. They are devs who want to get their apps out there quickly, not become apache experts. So they apt-get install apache, copy/paste the httpd.conf from the django docs, and they're done. If a django dev takes this same approach with nginx and gunicorn (for example) they are going to be better off than they would have been with apache/mod_wsgi.
But my other point, which you haven't addressed as much, is that apache is more difficult to troubleshoot when problems do arise. Because apache is a complex beast with lots of options and modules, it's very difficult for a non-expert to figure out where and why things have broken down. In my experience, the more simplistic servers are easier to troubleshoot (stands to reason, no?). I guess you are saying that this is no big deal because apache has a responsive and helpful support community, and that's fair enough, but I do think my point remains. After all, in spite of Graham coming through with The Perfect Config, I personally decided to not put myself through that experience again and moved away from apache on subsequent projects. I've been pleased with that decision, and I know many others share my experience. So anyway, there are two aspects -- the performance/stability aspect where I reckon we are in essential agreement, and then there is the troubleshooting/diagnosing aspect where I am advocating that apache is more complicated than the lighter servers. Hope that helps, --Stuart On Friday, January 13, 2012 10:04:42 AM UTC-6, Tom Evans wrote: > > On Fri, Jan 13, 2012 at 3:18 PM, Stuart Laughlin <stu...@bistrotech.net> > wrote: > > I hope you are not lumping me in with the relentless grudge-bearing > > apache attackers. (After all, I've already been accused of ad hominem > > attacks and some sort of fanboy me-too'ism on this thread [seriously > > guys, is this a tough room or what?]). I have nothing against apache > > per se -- it's a great server with a rich feature-set not found in the > > lighter servers. The only thing is, I don't want or need any of those > > extra features for my django projects. So the only things those extra > > features would contribute to my projects are additional complexity and > > inefficiency. Servers like nginx, lighttpd, and cherokee were designed > > specifically for people in this situation. > > I don't know what causes it, however this view - that lighty, nginx or > cherokee are higher performing than Apache - is just nonsense. It gets > rolled out whenever someone decides not to use Apache, and is without > basis in fact. Apache is also designed for extremely light weight > processes, if you configure it thus. > > [Side note - none of this is personal to you! I'm not trying to say > that you are the fore-front of a horde of rabid anti-Apache-ism, it's > just a common view that is propagated that really winds me up!] > > Apache covers almost every scenario related to HTTP, but commonly the > particular version that a distro will package up is not necessarily > the version that is correct for your particular scenario. Commonly, it > will come with every bell and whistle enabled, and using a > safe-but-slow request processing model, to accommodate mod_php. > > What happens is that someone who does not know how to use Apache uses > the stock version supplied by their distro, leaves all features > enabled, and then benchmarks it against lighty with a minimal > configuration, and draws incorrect conclusions. > > It's similar to benchmarking a Mercedes with a manual transmission > against a Ford with an automatic transmission, driving the Mercedes > only in first gear and concluding that the Ford is faster. > > > I'm not concerned with micro-performance enhancements. Nginx is > > clearly more efficient and performant than apache, but my main concern > > is being able to diagnose problems when they arise. I used apache/ > > mod_wsgi for my first few production deployments, and it was a very > > unpleasant experience -- weird memory usage statistics, users getting > > intermittent error messages, etc. -- and tracking down the problem was > > basically impossible. I found apache to be an opaque black box. The > > only thing that saved me was Graham Dumpleton sweeping in to rescue me > > with the perfect mod_wsgi config. He's the killer feature of django on > > apache as far as I'm concerned. > > > > Memory usage is one of the more common non-complaints aimed at Apache. > Apache does not usually leak memory, and process sizes normally stay > consistent for long long periods. The only time this does not happen > is when you embed a language interpreter and application inside > Apache, and that leaks. This is typical when running with mod_wsgi > embedded mode, and I would guess that Graham had you change your setup > to daemon mode. > > I would also say that Apache is a complex beast - there are lots of > options and modules. It also has a very responsive and helpful support > community. If anyone using Django needs help with any aspect of > Apache, try us...@httpd.org . > > Cheers > > Tom > > PS: I would agree that Graham is one of the top features of Apache :) > His mod_wsgi is excellent, and his support for Django is very > admirable, given that (IIRC) he doesn't actually use it himself much! > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/bGFS9lrNsXIJ. 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.
