On Apr 1, 1:21 pm, [EMAIL PROTECTED] wrote:
> Hey,
>
> I am currently looking at installing multiple instances of Django on a server
> to use Django as a teaching and learning tool.
>
> What is the best way to go about this?
>
> I want to minimise the amount of storage needed and optimize the performance
> of the server.
I wouldn't get too worried about performance, at least not speed. You
would probably find Django's internal development web server more than
adequate in a teaching environment and certainly would make restarts
when code changes easier to manage.
The only time internal server may be a problem is if writing complex
AJAX applications that expect to be able to have multiple concurrent
requests handled while prior requests haven't been completed. This
would be an issue because internal server is single threaded and
wouldn't allow concurrent requests which overlap in time. In other
words, all requests are serialised.
Only other real issue is the amount of memory used and as long as you
stick with Django development server, or use a hosting mechanism which
uses a single multithreaded process or non threaded this shouldn't be
a problem either. Use a multithreaded process though and you have to
start introducing students to issues of thread safety in programming.
People who do have problems with too much memory being used are often
trying to run Django embedded inside of Apache prefork processes on a
memory constrained VPS. In other words, you just need to pick the
right hosting technology. You also need to consider whether in the
time of the course whether students would develop enough stuff that it
would start consuming huge amounts of memory.
> I have heard that modwsgi can be used to specify different ports for each
> instance.
Technically, no it doesn't. There seems to be growing misunderstanding
in some quarters about how mod_wsgi works and this is one of the
misconceptions. The other main misconceptions are that mod_wsgi
implements some sort of wire protocol called WSGI and that the
'python' executable is actually launched as a separate process to run
the application. Neither of these is correct either.
What mod_wsgi does is implement the WSGI functional API specification.
This is to do with what happens within a Python process and how a web
server layer talks to a higher application layer. It has got nothing
to do with socket communications, its is a programmatic interface
only.
That all said, mod_wsgi does conceptually allow what you want in as
much as it does allow instances of applications to be run in separate
processes if you enable that feature. Those processes are though a
direct fork of the Apache parent process. Communications between these
processes and main Apache child processes is handled by UNIX sockets,
but that is actually totally irrelevant as the socket isn't the
defined public interface as it is with something like FASTCGI. Even
when run in the separate process the interface is still the
programmatic WSGI interface, mod_wsgi just handles it all
transparently and makes it work.
> I was a little concerned about using the same db for all the students, as if
> they make a bogus
query, update or insert on the db the whole db could be altered
unfavourably.
Again because I don't believe that performance should be your priority
in your setup, just use separate sqlite data for each user. This has
the benefit as well that you don't need to set up and manage a full
blown database system.
> Could the script used in this post be used to create subdomains for the
> users? Has this script has been written for just one instance of django?
If you set up each user with their own Django instance this would be
required in the first place.
> Is the easiest way going to be to create a directory for each user where a
> new instance of django is installed?
Pretty well. You just need to allocate them a separate listener socket
port number for them to use so they don't tread on each other though.
Anyway, all probably depends on how simple you want to keep it. :-)
Graham
> Any help or advice would be greatly appreciated.
>
> Thanks,
>
> Sarah
>
>
>
> ----- Original Message -----
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Tuesday, April 1, 2008 12:31 pm
> Subject: Re: Dynamic Subdomain Generation for Users
> To: Django users <django-users@googlegroups.com>
>
> > Thanks, Dan!
>
> > Just what I needed.
>
> > On Mar 31, 5:58 pm, Dan Ellis <[EMAIL PROTECTED]> wrote:
> > > Hi, Levi. I've just had a look through the code, and it
> > appears you're
> > > in luck (at least in the trunk -- I haven't looked elsewhere). core/
> > > handlers/base.py contains this line[1]:
>
> > > # Get urlconf from request object, if available.
> > Otherwise use
> > > default
> > > urlconf = getattr(request, "urlconf", settings.ROOT_URLCONF)
>
> > > It would appear that if the request contains an attribute called
> > > 'urlconf', that will be used instead of the default urls.py.
> > So all
> > > you need is a request middleware[2] that examines
> > > request.META["HTTP_HOST"] and sets the appropriate urlconf.
>
> > > Bah. On closer inspection of the docs, it appears this is already
> > > documented[3]. Still, it was a satisfying search ;-)
>
> > > Hope this helps,
> > > Dan
>
> > [1]http://code.djangoproject.com/browser/django/trunk/django/core/handle...>
> > [2]http://www.djangoproject.com/documentation/middleware/#process-request
>
> > [3]http://www.djangoproject.com/documentation/url_dispatch/#how-django-p...
>
> Sarah Vardy
> Research Computing Services
> Griffith University, Nathan QLD
> 0402241794
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
