Is there anyone out there using mod_wsgi on a high-traffic site who can vouch for how it performs?
If I were to switch all of my sites over to mod_wsgi over mod_python, would the server become CPU bound instead of memory-bound? On Oct 26, 7:10 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On Oct 26, 11:07 pm, Joe <[EMAIL PROTECTED]> wrote: > > > First off, I would warn anyone out there that with about 40 virtual > > hosts using Django, each apache (prefork) instance can get over 60 > > megs. We didn't realize this until the server started swapping, which > > was a disaster. > > > We were thinking that our only option was to switch to fast_cgi to > > reduce memory usage. > > > I would love to be able to keep apache and mod_python, so this would > > be good news. > > This is where mod_wsgi may be a better way of doing things. It can > still do embedded applications like mod_python for those sites which > have higher loads, but very simple to also delegate specific > applications off to smaller number of daemon process where having a > copy in every Apache child process isn't justified. To make the best > of daemon process in mod_wsgi, you would want to validate your Django > applications are multithread safe, as then you can use the daemon > processes in a worker mode rather than a prefork mode, thereby cutting > back further on numbers of processes required. The choice to have > worker or prefork mode for the mod_wsgi daemon processes is > independent of whether worker or prefork MPM is used for Apache > itself, so you can still run prefork MPM if you also need to run non > multithread safe PHP code. > > See mod_wsgi as a combination of mod_python and mod_fastcgi but a > somehwat simpler to configure and not need for a separate FASTCGI > adapter like flup. > > Graham > > > On Oct 24, 9:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > > wrote: > > > > On Wed, 2007-10-24 at 18:34 +0000, Joe wrote: > > > > If I understand this correctly, if you implemented this, could I use > > > > the same python interpreter between multiple virtual hosts and not > > > > worry about overlap? > > > > That's the rough goal, yes. Complete sandboxing might not be possible, > > > because it would be nice to share memory usage (as Graham mentioned in > > > his reply), however that would mean that any poking into the common > > > modules' namespaces that one site did would affect all the other sites > > > using that module: for example, if you added something to contrib.auth > > > (just to pull a name out of the hat) by replacing > > > contrib.auth.models.Auth.get_absolute_url, say, *all* sites would see > > > that change. That's a little less contained than I would really like, > > > but it's the trade-off for sharing memory. I haven't thought about this > > > enough to feel confident going either way, yet. > > > > Realise that this is all still in the planning phase because I have to > > > get queryset-refactor finished along with other regular maintainer work > > > done, too. But I've got at least two long plane flights coming up in the > > > next month, so that should give me some time to think about things and > > > work on an implementation. > > > > Regards, > > > Malcolm > > > > -- > > > Always try to be modest and be proud of > > > it!http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
