Now for some more comments. On Mar 28, 2:01 am, Peter Rowell <[EMAIL PROTECTED]> wrote: > In another thread (http://groups.google.com/group/django-users/ > browse_thread/thread/962cfdf7609839eb/), > > On Mar 23, 11:48 pm, Graham Dumpleton <[EMAIL PROTECTED]> > wrote: > > > For example, using prefork MPM because PHP is not thread safe in > > conjunction with Python web applications in embedded mode in a memory > > constrained VPS is a bad idea. You either ditch PHP and use worker > > MPM, or you go to mod_wsgi and use daemon mode for the Python web > > application. > > He said it with authority. After perusing his site (in > particular,http://www.dscpl.com.au/wiki/ModPython/Articles), it would appear > that > he speaks from intimate knowledge of the issue. > > His statement bothered me for two reasons: > > 1. It was at odds with the Django docs (http://www.djangoproject.com/ > documentation/modpython/), which specifically say "you should use > Apache's prefork MPM, as opposed to the worker MPM."
Part of the reasoning for this was that prefork was single threaded and Django wasn't originally written with threading in mind. There were also issues back then with some database adapters not being thread safe. Thus it was erring on the side of caution. These days a lot of people use Django on Windows and with FASTCGI in multithreaded configurations and Django documentation even covers those multithreaded configurations. > 2. Because it forced me to confront my own ignorance of exactly *why* > prefork MPM is preferred (absolutely required?) over worker MPM. > > Questions: > > + What is it about python and/or Django that forces(?) the use of > prefork MPM rather than worker MPM? These days there isn't really anything, except maybe perhaps the thread safety of your own code on top of Django and any special third party modules you may use. Thus why you simply need to make sure you test your own code on a comparable setup before production deployment. > + Does this have to do with python's GIL (global interpreter lock)? Not at all. Some will argue that the GIL affects multithreaded performance, but in practice for web applications running under Apache it doesn't have as great an effect as a non web application running in a standalone process. See: http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html > + Is there some inherent non-thread-safe aspect of either? Globals? > Database caching? There can be if access wasn't coded to be thread safe. > + Or is it, as Graham suggests, that it is the combination of PHP and > Python that requires prefork? I can't remember what the original conversation was about but possibly what I was talking about was that if you want to cut down on memory usage, you can reduce the number of Apache child processes by using worker MPM instead of prefork MPM. The problem with switching to worker MPM is that you can cause problems if you are also using PHP within the same web server. This is because not all third party modules for PHP may not be thread safe. Older versions of PHP may also not be thread safe from memory. These issues cause a problem for PHP applications, not the Python application. > Inquiring minds want to know. Hopefully that and the document I pointed at previously explains things a bit better. Otherwise you may need to explain your concerns a bit better. Graham --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
