On Oct 11, 9:23 am, mguthrie <[EMAIL PROTECTED]> wrote:
> I had read in more than one place that a django instance can eat up to
> 10mb - 30mb of memory. I don't know whether that is fact or fiction
> and I'm also confused by the term instance. Is an instance defined as
> multiple different Django projects or a single Django project used
> multiple times? If it is true that one Django project used across
> multiple <Location>'s eats up that much memory I wouldn't able able to
> host very many clients on a server.
>
> I'm trying to devise my infrastructure ahead of time so I'm not stuck
> with a finished application that can't be hosted for many clients.
The comment by Colin about use of multiple sub interpreters not
requiring much more memory is true, but misleading. This is because as
you suspect the main issue is how much Django itself takes and not the
overhead of mod_python or Python sub interpreters.
The problem with using mod_python is that Django instances run in sub
interpreters of Apache child worker processes, thus, how much overall
memory used is in part dictated by which Apache MPM you are using and
how many processes Apache has been configured to use. To clarify,
Apache on UNIX is a multiprocess web server. Thus there isn't just one
instance of Django per site, but number of Apache child worker
processes multiplied by the number of sites.
If you are are using Apache prefork MPM, it is not uncommon to use a
configuration that sees minimum 10-20 processes and maximum of 100.
Thus, if you had 5 sites each running at minimal 20MB, worst case
where Apache had to create maximum number of processes to handle load,
would be 5*20*100 MB. A lot of Django sites run with lot more memory
than 20MB.
Using Apache worker MPM, where each Apache child worker process is
multithreaded can be better, as in that case configuration would
normally see maximum of 5-10 processes. So, maximum would be 5*20*10
MB, which is a lot less.
To use Apache worker MPM though, you would need to use Django 1.0 as
older versions had some question marks over their readiness for
multithreaded use. Your application itself would also need to
multithread safe.
Now, for another option, you may want to use mod_wsgi instead. Whether
you use Apache prefork or worker MPM, with mod_wsgi you would create a
daemon process group for each site and delegate specific WSGI
applications for each site to run in their own daemon group processes.
Using daemon mode gives various benefits. These are they each site
runs in its own processes and no risk of each interfering with each
other. Each site can run as a distinct user. Individual sites can be
restarted without restarting whole of Apache. And the number of
processes used by each site can be be better controlled, with it being
independent of MPM used and how many Apache child worker processes
there are.
In summary, if you need to be mindful of memory usage, you would be
better of using mod_wsgi and its daemon mode. This is because it gives
you separate control over number of processes in use for each site and
number of processes fixed and isn't variable based on load and Apache
making a decision to create more worker processes.
Note that mod_wsgi and daemon mode doesn't preclude you still running
a site within embedded mode, ie., in Apache child worker processes, at
the same time if you feel that the bit of extra speed coming from
embedded mode is important to you for a specific site.
Graham
> Thanks for replying.
>
> -MG
>
> On Oct 10, 2:58 pm, "Colin Bean" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Oct 10, 2008 at 12:34 PM, mguthrie <[EMAIL PROTECTED]> wrote:
>
> > > I've been looking into Django for building something that is more web
> > > application than it is website. I understand that Django has been
> > > developed in a sort of CMS mindset but to date I haven't found any
> > > reason why it couldn't create non-content centric web apps as well.
>
> > > My project requirements are as follows:
>
> > > 1.) I need to be able to host this project for multiple clients. No
> > > customization, just everybody using the same thing. Therefore ideally
> > > they should all share the same codebase.
> > > 2.) Each client should have their own user table/authentication since
> > > I want client A to be able to have a user named john.doe and client B
> > > to as well. I would not mind if they shared the same table but they
> > > needed to provide a client id so the login can differentiate.
> > > 3.) Media should be separate per client. Client A media should not be
> > > mixed with Client B or vice versa.
> > > 4.) Database either needs to be single db per client or one large db
> > > with multiple prefixed tables per client. So each client would get
> > > their own users table (or shared table with client id field), tables
> > > for data, etc.
>
> > > I've researched the options available and here's what I've found
> > > (correct me if I'm wrong):
> > > 1.) I can host each client separately by providing a different
> > > <Location> for each and specifying a different settings file. This
> > > should allow me to specify separate DB's, media locations, etc but I'm
> > > concerned about the overhead of hosting them. I've read that for each
> > > instance of Django requires another python interpreter. If that is
> > > the case wouldn't I run out of RAM quickly hosting several clients?
> > > Is there a way I can do this using only one instance of Django? If I
> > > use Django with multiple <Location>'s per client would that be one
> > > Django instance or multiple? Ismod_pythonnot the way to go for this
> > > project?
> > > 2.) I can use django.contrib.sites but every client shares the
> > > authentication. Is there a way I can specify a client id to
> > > distinguish Client A's john.doe from Client B's? If I do this can I
> > > specify where media for either would go? How about they all share the
> > > same DB but have different table prefixes?
>
> > > I know it's a lot but I wanted to be as specific as I could so I don't
> > > waste someone's time. Is Django probably the wrong framework for this
> > > project? Should this be a Pylons/Turbogears thing or what?
>
> > > All ideas/critiques/reworkings will be accepted. Thanks in advance.
>
> > > -MG
>
> > Django is quite capable of doing everything you described. You've
> > almost answered your own question because hosting separate django
> > instances under different <Location> directives (or virtual hosts)
> > seems like the ideal solution. I wouldn't worry too much about the
> > overhead of multiple python interpreters -- if python is using shared
> > libraries, they will use a little extra ram, but I doubt they will
> > exhaust your system resources before something else does. I don't
> > have any numbers to back this, but I've run several django instances
> > on a single host with no problem, and it seems to be fairly common
> > practice.
>
> > Colin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
