On May 22, 2:38 am, puff <[EMAIL PROTECTED]> wrote:
> Thanks Graham and Ben for the prompt feedback. It was most helpful.
>
> > Depending on the hosting mechanism has been configured, anyDjango
> > startup may only happen the first time a request comes in. This would
> > potentially delay requests if the initialisation takes a while.
>
> Our current hosting intent is Apache per the current configuration
> recommendations. Unfortunately, I'm not familiar with Arache/mod-
> Python so I'm on unknown ground. Initialization time is not an issue
> as the system as a whole takes a few minutes to come up as multiple
> servers and daemons are involved.
If it takes a few minutes to load and setup your Django instance it is
a huge issue. This is because Apache can kill off and create
additional child processes when it feels it needs to. If the startup
time of your Django instance is significant, this would be a dreadful
experience for the user as their requests would appear to hang for a
while.
> If I understand your feedback
> properly, it sounds like startup.py isn't processed until the first
> timeDjangois tickled. That being the case it would appear sensible
> to have something external toDjango/Apache post to a URI to cause
> initialization. Does this seem reasonable?
You don't need to trigger it to be loaded externally to Apache. As I
said, you need to look at what the hosting mechanism provides to allow
code to be run at process startup automatically, before any requests
are handled.
In the case of mod_python you need to look at the PythonImport
directive. In the case of mod_wsgi you need to look at the
WSGIImportScript directive.
The module/script which the directive refers to would contain
something like:
import os, sys
sys.path.append('/usr/local/django')
sys.path.append('/usr/local/django/mysite')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
Now, if you are observant you would see that you don't need to add
anything to the Django startup.py script as you could just do it in
this module/script itself after the initial import is done.
In the case of mod_wsgi, the WSGIImportScript could refer to the exact
same script file you are using with WSGIScriptAlias.
If putting startup code in the WSGI script file, for mod_wsgi embedded
mode, you might want to turn off script reloading to avoid things
being done successive times if you inadvertently modify the WSGI
script file or touch it.
> > > Part of the application involves running an external application on a
> > > scheduled basis.
>
> > Apache is a multiprocess web server. Does it matter that your request
> > is going to only one of the possible many processes which may be
> > running?
>
> Hmmm. I'd not considered that. Part of the requirement here is that
> one and only one of these scheduled things be running at a time. The
> tentative approach is to queue the cron generated items for later
> consumption by a separate process. That being the case, it appears
> that I don't really care what process services the cron URI. Thanks
> for pointing it out.
More reason then for such processing to be split into a back end
process, or be done from standalone scripts executed from some
scheduler such as cron.
> Do I understand correctly from your feedback that there may be
> manyDjangoprocesses running within Apache/mod-Python?
Yes. See:
http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
What you read there for mod_wsgi embedded mode also applies to
mod_python in practice, just that mod_python isn't going through a
WSGI interface.
> > Do note it is possible to write standalone scripts that import your
> >Djangoinstance and thus allow you to do stuff on the database outside
> > of the context of an Apache process.
>
> Can you give me a pointer?
See example code above. All it needs to do is setup sys.path if
required and define where settings module is. You then have Django
loaded and can use APIs it provides as necessary to do stuff.
In other words, you don't have to be running under a web server
environment. What APIs in Django can be used in this context and how I
cant tell you as I don't use Django to any degree to know.
> > > What, if any, issues are there with a daemon like process running
> > > withinDjango/Apache?
>
> > Do you mean a daemonisedthreadrunning in Apache processes? Running
> >Djangounder Apache is not an issue, so not sure if you mean something
> > else.
>
> I didn't explain myself very well here. The application needs to
> maintain a work queue. Work arrives via URI post and is enqueued to a
> work queue. When work arrives the python method that processes the
> work queue needs to be started if necessary. It dequeues work items
> in turn and performs them. The work involves either sending a URI to
> another web service to cause the work to happen or executing an
> external application such as RSYNC. In either case progress needs to
> be monitored and recorded. The current approach is to start the
> method that consumes the work queue and let it run indefinitely.
> Since I'm unfamiliar withDjango/Apache/mod-Python I'm uncertain of
> what, if any, issues this approach has.
Run a backend process and do that sort of stuff in it.
Alternatively, if you use mod_wsgi you can use its daemon mode feature
to run a subset of the Django URLs in a daemon process all by itself.
This means that Apache/mod_wsgi will manage startup and shutdown of
the process for you. Provided that you tell mod_wsgi to only create
one process for that subset of URLs, no worries about what process it
may go to as there will only be one. You can still then use a specific
URL to trigger any execution of work if need be, but may not be
necessary as the script triggered using WSGIImportScript could for
that one process create background threads that do things from time of
startup.
> > You may perhaps want to split out any long running activities from the
> >Djangoprocesses running in Apache into a separate backend server
> > independent from Apache. That backend process can be a true long
> > running process, where as with processes under Apache, they can be
> > recycled by Apache which may be an issue where an activity is
> > interrupted.
>
> We are using that approach in one part of the system already and
> considering it for dealing with the work queue.
As above, use of a mod_wsgi daemon process may be a strange middle
ground for doing this. In effect you are using Apache/mod_wsgi as a
process supervisor as well as HTTP interface into your application
components.
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
