views:

26

answers:

2

I am running Django under Apache+mod_wsgi in daemon mode with the following config:

WSGIDaemonProcess myserver processes=2 threads=15

My application does some IO on the backend, which could take several seconds.

def my_django_view:
    content=... # Do some processing on backend file
    return HttpResponse(content)

It appears that if I am processing more than 2 http requests that are handling this kind of IO, Django will simply block until one of the previous requests completes.

Is this expected behavior? Shouldn't threading help alleviate this i.e. shouldn't I be able to process up to 15 separate requests for a given WSGI process, before I see this kind of wait?

Or am I missing something here?

+2  A: 

If the processing is in python, then Global Interpreter Lock is not being released -- in a single python process only one thread of python code can be executing at a time. The GIL is usually released inside C code though -- like most I/O, for example.

If this kind of processing is going to happen a lot, you might consider running a second "worker" application as a deamon, reading tasks from the database, performing the operations and writing resulsts back to the database. Apache might decide to kill processes that take too long to respond.

Radomir Dopieralski
Hmm - not sure if the GIL applies in this case:http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
shreddd
Not sure myself -- there might be a lock on the database connection or whatever the long-I/O is doing too -- for example sqlite3 allows only one writer at a time.
Radomir Dopieralski
This could be made clearer. Although only Python code within one thread at a time can run because of the GIL, a thread running Python code will yield control up to another thread running Python code on a regular basis. Thus you can still have concurrent requests, but where the operation is CPU bound then the GIL will limit your ability to utilise multiple CPUs given that only one Python code thread can be run at a time and not multiple across multiple CPUs. I/O bound threads aren't as big an issue as described in 'http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html'.
Graham Dumpleton
Further, Apache under normal circumstances isn't going to go kill off processes. Usually killing off of processes when requests take too long is a feature of modules for FASTCGI and mod_wsgi. For mod_wsgi the ability to have processes forcibly killed off only relates to daemon mode and it has to be configured as is not the default. It also isn't a strict request timeout, but is handled as an inactivity timeout. That is, a processes that appears not to be consuming or producing any content any more. See 'http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess'.
Graham Dumpleton
+2  A: 

+1 to Radomir Dopieralski's answer.

If the task takes long you should delegate it to a process outside the request-response cycle, either by using a standard cron, or some distributed task queue like Celery

Lakshman Prasad