Graham, Thanks for the detailed response. I have yet to get too much into the internals of Apache in regards to Python applications. My background is in PHP which is a whole different beast with it's own unique way of being tweaked. I'll have to look into the mod_wsgi setup you mentioned. I've heard a lot of things regarding wsgi with other Python projects. Discussing all of this has made me re-think my approach and whether Django will be a good fit for this specific project. It may be better for me to simply use a different python framework and let the client separation be handled via the application and not separated out by Apache or any other server (lighttpd, nginx, etc). Like I noted my background is in PHP development so understanding the Python way of doing things is new territory for me. Thanks for the feedback.
-MG On Oct 10, 6:29 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
