Cliff Wells wrote: > On Tue, 2008-05-20 at 13:49 -0400, Ross Vandegrift wrote: > > On Mon, May 19, 2008 at 09:10:27PM -0700, Jonathan Vanasco wrote: > > > so is Apache considered to be a good thing (through mod_wsgi , > > > mod_python , or other ?) > > > > > > i've been doing mod_perl dev for years, and have had some experience > > > with mod_python -- generally speaking, my experience is that if you > > > can avoid apache you're better off. i guess that's what is throwing > > > me off. i equate apache with "isn't there a better way now?" > > > > I don't mean to come off as sounding curt, but I've often heard that > > from people who haven't really maintained the alternatives. Or that > > have an application that gets deployed in a highly isolated environment, > > where interoperability means nothing.
Using mod_perl as an indicator is actually a bad idea. This is because it tends to be the worst of the bunch when it comes to bloating out Apache. Thus saying that all solutions which embed an interpreter in Apache are bad based on what one sees with mod_perl is not a good idea. The mod_python module does carry a bit more bloat in its base level memory profile than it needs to and this has been identified and discussed on mod_python lists, although nothing down about it yet even though changes relatively simple to address it. The main reason though why mod_python has got a bad reputation for memory usage is threefold. The first is that older versions of mod_python leaked memory. This has been addressed in later versions. The second is that the Python installation being used didn't provide a usable shared library for Python itself and instead there was only a static library. This mean that a static copy of Python was being included in mod_python module. Because of shared library issues this was being converted to local process memory rather than being shared and so base level process sizes were more than they need to. So, install your Python properly and you will avoid this issue. It has also only been the last year or so that Linux distributions have been fixing their Python installations to provide a usable Python shared library. The third reason is simply that Python web applications can get fat, especially when people developing the applications don't take memory usage into consideration at all. Unfortunately people see the large processes sizes caused by their own application, especially when viewed in conjunction with fact that Apache is a multi processor server, and so there are multiple copies, and wrongly think it is mod_python that is causing their problems. Instead it is their own fat application and a lack of understanding of how Apache works and how to configure it so as to limit resource usage. So, although mod_python is at fault a little bit, in the main it is actually factors outside of mod_python. FWIW, mod_wsgi uses even less base level memory than mod_python. As with mod_python, it is still affected by poor Python installations and fat applications being run on it. The mod_wsgi module provides better flexibility however in being able to control memory usage through process recycling. > > Frankly, the flexability of Apache is what makes it so much better > > than the alternatives. It has solid support for just about anything > > related to the web. It has excellent, complete documentation > > surrounded by a large, knowledgeable user community. > > I'd qualify this paragraph as "some of Apache's strengths are", rather > than a blanket "it's better". For some people, in some settings, it is > better. For others it isn't. If you need high scalability, it isn't > the best. If you need a small memory footprint it's not the best. If > you prefer a sane configuration syntax it isn't the best. If you need > all three then it's arguably amongst the worst. What is silly is people who think that any one web server is going to be the complete solution anyway. One gets truly sick of people asking what is the fastest web server to use as there is so much more to that. Speed does not equate to scalability, and just because one server is fast at serving static files doesn't mean it is good for dynamic web applications. So, servers like nginx and lighttpd will be better than Apache for handling serving of static files. Just because they are though, doesn't mean you should also then use them to host your dynamic web application code. For a Python web site with a requirement to also serve up a lot of static media files, one would definitely want to use a separate nginx or lighttpd server, or even use a specialised CDN. This should be run on its own servers and not on the same server as your web application. As to your dynamic Python code, it would generally be best served as I said before by running Apache prefork MPM with code running directly in Apache processes, ie., embedded mode of mod_wsgi. That server would be dedicated to running just the Python web application code, no static files sharing, no sharing the server with PHP or any other stuff. With a dynamic application, you can also benefit from doing things like turning off keep alive as in general one page will not generate successive requests against the Python web application. You would still use keep alive on on the static media servers though as that is where you would benefit from it. Using it for dynamic web application, you are only going to serve to tie up connections longer than you need to and thus waste resources. Anyway, there are a lot of other things you can do as well, especially in your application space and how you construct your HTML code so as to allow browsers to parallelise loading as much as possible. So, things are not as simple as most think it is going to be. There is a lot to building what is required for large scalable sites and starting with the belief that a single server type is going to do everything you want isn't going to help as down the line it may just cause you to hit any performance wall quicker. In summary, use each tool for what it is good at. Don't try and make one thing do everything. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
