Another note:, the peak load we see on the site is around 60 or 70
requests per second.  With 4 gigs of ram and each apache instance
weighing in at 60 megs, we can only start 67 apache processes, which
can sometimes cause problems.

The processor is a quad core Xeon, so it is not being used to full
capacity.

I think our end goal is to use less ram and more processor.

On Oct 29, 12:46 pm, Joe <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to