On Jul 16, 3:05 pm, John Nagle <na...@animats.com> wrote: > alex23 wrote: > > On Jul 16, 2:03 pm, John Nagle <na...@animats.com> wrote: > >> "fcgi" is an option for this sort of thing. With "mod_fcgi" installed > >> in Apache, and "fcgi.py" used to manage the Python side of the problem, you > >> can have semi-persistent programs started up and shut down for you on the > >> server side. > > > Hey John, > > > The environments in which I've been asked to develop webs apps using > > Python have all utilisedmod_wsgi. Do you have any experience with > >mod_wsgivs mod_fcgi, and if so, can you comment on any relevant > > performance / capability / ease-of-use differences? > > > Cheers, > > alex23 > > FCGI seems to be somewhat out of favor, perhaps because it isn't > complicated enough.
I doubt that is the reason. It is out of favour for Python web hosting at least, because web hosting companies provide really crappy support for using Python with it and also don't like long lived processes. Most FASTCGI deployments are configured in a way more appropriate for PHP because that is what the default settings favour. This works to the detriment of Python. Even when people setup FASTCGI themselves, they still don't play with the configuration to optimise it for their specific Python application. Thus it can still run poorly. > It's a mature technology and works reasonably well. But is showing its age. It really needs a refresh. Various of its design decisions were from when network speeds and bandwidth were much lower and this complicates the design. Making the protocol format simpler in some areas would make it easier to implement. The protocol could also be built on to make process management more flexible, rather than relying on each implementation to come up with adhoc ways of managing it. Part of the problem with FASTCGI, or hosting of dynamic applications in general, is that web servers primary focus is serving of static files. Any support for dynamic web applications is more of a bolt on feature. Thus, web applications using Python will always be at a disadvantage. PHP manages okay because their model of operation is closer to the one shot processing of static files. Python requires persistent to work adequately with modern fat applications. > It's been a puzzle to me that FCGI was taken out of the > main Apache code base, because it gives production-level performance > with CGI-type simplicity. As far as I know FASTCGI support has in the past never been a part of the Apache code base. Both mod_fastcgi and mod_fcgid were developed by independent people and not under the ASF. In Apache 2.3 development versions (to become 2.4 when released), there will however be a mod_proxy_fcgi. The ASF has also taken over management of mod_fcgid and working out how that may be incorporated into future Apache versions. > WSGI has a mode for running Python inside the Apache process, > which is less secure and doesn't allow multiple Python processes. Depending on the requirements it is more than adequate and if configured correctly gives better performance and scalability. Not everyone runs in a shared hosting environment. The different modes of mod_wsgi therefore give choice. > That complicates mod_wsgi considerably, No it doesn't. It is actual daemon mode that complicates things, not embedded mode. > and ties it very closely > to specific versions of Python and Python modules. As a result, > the WSGI developers are patching at a great rate. What are you talking about when you say 'As a result, the WSGI developers are patching at a great rate'? As with some of your other comments, this is leaning towards being FUD and nothing more. There is no 'patching at a great rate' going on. > I think the thing has too many "l33t features". It is all about choice and providing flexibility. You may not see a need for certain features, but it doesn't mean other people don't have a need for it. > I'd avoid "embedded mode". "Daemon mode" is the way to go if you use WSGI. I'd agree, but not sure you really understand the reasons for why it would be preferred. > I haven't tried WSGI; Then why comment on it as if you are knowledgeable on it. > I don't need the grief of a package under heavy development. More FUD. Graham -- http://mail.python.org/mailman/listinfo/python-list
