Does mod_wsgi (daemon) sites hand off content to apache to serve to the client?

Question

I have Django deployed with mod_wsgi in daemon mode for apache2.2. So after Django churns out the content, does it hand off everything to apache from there to have it served in its optimised glory or is Django still somehow taxed in this serving step?

Answer 1

WSGI interface says (http://www.python.org/dev/peps/pep-0333/) that your WSGI application (Django in this case) is called, and must return the content.

Django called your view function. Your view function returned a rendered template. Django returned results of rendering the template. And, on your behalf, it invoked the start_response callable.

Working backwards another step, Apache invoked mod_wsgi. mod_wsgi (following the WSGI rules) created the environment and handed this to Django, along with astart_response callable that Django can use.

When Django called start_response, mod_wsgi was obligated to collect that response and do something with it. It hands it to Apache to be fed down to the browser.

Note that Django may be done in a pretty big hurry. Apache, however, is stuck trickling the initial page down to the browser. Then, the browser starts asking for .JS libraries, .CSS files, and all those images. Ideally Apache handles all the rest of these follow-on requests.

---

You might be asking "does mod_wsgi buffer for me?" The answer varies with version. Pre 2.0 mod_wsgi could accumulate a buffer for you. mod_wsgi 2.0 and up doesn't buffer, it assumes that the application is capable of buffering, or has included middleware for buffering.

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0200

Generally, your Django template is rendered in one buffer and handed to mod_wsgi in one piece, ready for Apache to apply output filters and trickle it down to a browser.

Answer 2

FWIW, in mod_wsgi 1.X, allowing Apache to perform output buffering was off by default. This is because WSGI specification effectively prohibits output buffering by the underlying web server. This is because WSGI specification requires that data be flushed back to the browser after each string returned from the iterable/generator.

In other words, enabling output buffering was optional and more an experiment than anything else. It was removed because WSGI prohibited it and because it actually complicated the mod_wsgi code when it was necessary to implement some work arounds for incorrect behaviour in certain Apache versions.