On Dec 29, 4:38 pm, iain duncan <[EMAIL PROTECTED]> wrote: > On Fri, 2007-28-12 at 21:19 -0800, Graham Dumpleton wrote: > > iain duncan wrote: > > > I have read the docs on mod_wsgi and it seems really cool ( thanks > > > Graham! ) but I'm wondering if others who know more about servers could > > > comment on what the pros and cons are of using mod_wsgi compared to > > > running cherrypy in a separate process and using mod_proxy. > > > A few things to start the conversation. Most interested still in > > others comments though. There are a few people going around telling > > fibs about mod_wsgi in an attempt to discredit it, so if you have > > heard negative points about it would love to hear them so can either > > set the record straight, or at least understand why people think it > > may not be suitable in certain contexts so it might be improved > > further if necessary. > > Thanks Graham. I admire that you don't want to get into the mudslinging, > but could you possibly let us know what these misconceptions are?
Claims include that because it is bound to a specific version of Python that it greatly complicates your upgrade process. This is really over emphasing the problem as any complicated system running as a production environment is going to have to be upgraded with care and with a good plan. It is true that upgrading Apache and Python together will not be as simple as changing which version of Python a CherryPy system is using, but for a production system it isn't like you are going to change which version of software you use everyday. Thus it is a specious argument in some respects. That because Apache is embedding the Python interpreter that your processes use huge amounts of memory. This claim probably stems from the fact that until the last couple of years, many Linux distributions did not provide a version of Python that included a shared library. Because it was a static library it had to be embedded into the Apache module for mod_wsgi. When this was loaded, because it was static code address relocations had to be done which turned it into local private memory. This could mean that each process could immediately start using 3MB+ than it was before. In other words it was actually a problem with the Python installation being used and nothing to do with mod_wsgi, whose base memory profile is only a few hundred KBs. Yes the processes will start to become large when you load your WSGI application, but that is the WSGI application and it will take up just as much memory if running it in a standalone process. Anyway, this issue is clearly documented in mod_wsgi installation notes. That because the Apache server also embeds other Apache modules for other programming languages such as PHP or mod_perl that you will have no end of problems where each wants to use a similar set of client libraries for a database or other back end system. The problem here is where where people grab precompiled modules for each of those systems rather than build them themselves. The result can be that the precompiled modules may have been compiled against different versions of a shared library and so there may be mismatches in the APIs causing crashes as only one version of a shared library can be used by a process. Can't deny that this is an issue, but all the known systems that this occurs for are documented as issues in mod_wsgi documentation and there is no attempt to hide them. In general the problems don't exist where people build the software themselves. Once again they have been taking a manageable issue and blowing it all out of proportions. That debugging WSGI applications is somehow harder when being run under Apache. The mod_wsgi documentation actually covers various bits and pieces about debugging applications and it isn't really much harder than trying to debug them in a standalone Python process. It does help though to run the application to be debugged in a single daemon mode process as then one can use one of the interactive WSGI application debuggers which otherwise don't work in multiprocess web servers. Basically the people try and take what are minor things in respect of the above and make it seem like it is the end of the world. They were also going around making blatantly false claims like mod_wsgi crashes all the time and that the majority of people who have tried it have problems with it. These days they have toned down their rhetoric and usually just say that mod_wsgi is evil and that you shouldn't use it. When anyone asks why it is evil they just shut up and don't given any reasons. It is becoming more and more obvious that one person in particular probably has some personal vendetta against me because I took them to task over making many of the same incorrect claims about mod_python. It is actually quite funny at times some of the things they say, but then also quite sad because none of their peers in the Python sub community they operate in try and pull them into line as far as the false claims they were making. From what I've seen, that person has only managed to damage their own standing, but in the interim it is also reflecting badly on that Python sub community. Hopefully one day they will see the sense in giving constructive criticism with the aim of improving quality of software through feedback rather than being negative and just trying to make people not use a piece of software because they don't like it. > What is the status on getting mod_wsgi accepted into common apache > bundles? Mostly out of my hands. Some one does package it for Debian for me and it is progressing through the various levels of Debian acceptance. Once it gets through into Debian most will probably automatically pick it up. You can gauge progress by looking at: http://packages.qa.debian.org/m/mod-wsgi.html I don't really understand the Debian process, so not sure how much further it has to go. > Seems like it would be a great thing to have available instead > of fast_cgi. For Python at least that is the aim. I am still not confident that will happen though for the reason that commodity web hosters use FASTCGI because it is a solution for various languages such as Python, PHP, Perl etc. So, they only have to manage one package. With mod_wsgi one is asking them to install a separate package just for handling Python, which although is base memory overhead in core Apache processes when using daemon mode is minimal, it is still an extra package that they have to wear the overhead of. So, unless mod_wsgi is really compelling it will probably be a long long time before commodity web hosters pick it up and support it. Only thing that might change that is if some of the Python web frameworks really take off in the way that Ruby on Rails does and are seen as the new fad, resulting in a knew jerk reaction from companies to try and support it easily. This doesn't mean that you will not see it being an option for VPS systems and maybe specialised web hosting companies who promote good Python support. Although, one of the main web hosting companies with a preference for Python have said that although they are watching mod_wsgi, that they have no intention of using it as they see there current mod_python based systems more than adequate. > And can you comment on any cons of mod_wsgi? ( knowing of > course that you are biased. ) I actually hope I am reasonably up front with what the problems are. I have even blogged about some of them. The major shortcoming is lack of proper transient process support like mod_fastcgi has. That is, that the daemon process is only created on demand the first time it is required, with the process being completely shutdown after some period of inactivity. This is very important for commodity web hosting, but will not be addressing this until mod_wsgi version 3.0. When using daemon mode of mod_wsgi, the way it is implemented means that it currently suffers from a potential problem that running CGI scripts on Apache also does. This is where if an application doesn't consume all the request content before sending back a response over a certain size that a temporary deadlock can occur in the socket read/ writes across the connection between the Apache child process and daemon process. It will only unblock itself after a set timeout expires. A well behaved application wouldn't generally hit the problem, but some of the spam bots on the network have inadvertently triggered it in some applications. I'll look at changes to avoid the potential for this in mod_wsgi 3.0. FWIW, the CherryPy web server also has a strange problem with applications that don't consume all the request content. The issue there manifests where keep alive is used and multiple request sent down the one socket connection. I knew about issues with CherryPy web server in they way it did this, but it actually came up in discussion today on web.py group. http://groups.google.com/group/webpy/browse_frm/thread/ab38f59e351d536d Finally, one could argue that being bound to a single version of Python may become an issue in commodity web hosting environments where users want choice and packages have certain version requirements. For example, what if only some want to use Python 3.0. I have discussed this issue a bit before on mod_wsgi list and if I think it becomes warranted, am looking at a hybrid exec mode for mod_wsgi in version 4.0 whereby instead of daemon process being just a fork, it would fork/ exec a distinct Python process which immediately loads up a mod_wsgi daemon side runtime which then makes everything look like it was a normal daemon mode process with the exception that arbitrary Python version could be used. Other than those few issues, overall, I at least believe that mod_wsgi is going quite well so far. There is a lot more it could do, but various people are trying to keep my grand plans in check and make me focus on just WSGI support rather than opening it up as a more general platform for using Python with Apache. :-) Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
