views:

687

answers:

3

I have Django running in Apache via mod_wsgi. I believe Django is caching my pages server-side, which is causing some of the functionality to not work correctly.

I have a countdown timer that works by getting the current server time, determining the remaining countdown time, and outputting that number to the HTML template. A javascript countdown timer then takes over and runs the countdown for the user.

The problem arises when the user refreshes the page, or navigates to a different page with the countdown timer. The timer appears to jump around to different times sporadically, usually going back to the same time over and over again on each refresh.

Using HTTPFox, the page is not being loaded from my browser cache, so it looks like either Django or Apache is caching the page. Is there any way to disable this functionality? I'm not going to have enough traffic to worry about caching the script output. Or am I completely wrong about why this is happening?

[Edit] From the posts below, it looks like caching is disabled in Django, which means it must be happening elsewhere, perhaps in Apache?

[Edit] I have a more thorough description of what is happening: For the first 7 (or so) requests made to the server, the pages are rendered by the script and returned, although each of those 7 pages seems to be cached as it shows up later. On the 8th request, the server serves up the first page. On the 9th request, it serves up the second page, and so on in a cycle. This lasts until I restart apache, when the process starts over again.

[Edit] I have configured mod_wsgi to run only one process at a time, which causes the timer to reset to the same value in every case. Interestingly though, there's another component on my page that displays a random image on each request, using order('?'), and that does refresh with different images each time, which would indicate the caching is happening in Django and not in Apache.

[Edit] In light of the previous edit, I went back and reviewed the relevant views.py file, finding that the countdown start variable was being set globally in the module, outside of the view functions. Moving that setting inside the view functions resolved the problem. So it turned out not to be a caching issue after all. Thanks everyone for your help on this.

+1  A: 

Did you specifically setup Django caching? From the docs it seems you would clearly know if Django was caching as it requires work beforehand to get it working. Specifically, you need to define where the cached files are saved.

http://docs.djangoproject.com/en/dev/topics/cache/

PKKid
I didn't do any of this preliminary work, so I guess the Django caching is disabled... Any ideas what else could be causing the issue with the timer start time being cached? Could apache with mod_wsgi be doing this?
Travis
+3  A: 

From my experience with mod_wsgi in Apache, it is highly unlikely that they are causing caching. A couple of things to try:

  1. It is possible that you have some proxy server between your computer and the web server that is appropriately or inappropriately caching pages. Sometimes ISPs run proxy servers to reduce bandwidth outside their network. Can you please provide the HTTP headers for a page that is getting cached (Firebug can give these to you). Headers that I would specifically be interested in include Cache-Control, Expires, Last-Modified, and ETag.
  2. Can you post your MIDDLEWARE_CLASSES from your settings.py file. It possible that you have a Middleware that performs caching for you.
  3. Can you grep your code for the following items "load cache", "django.core.cache", and "cache_page". A *grep -R "search" ** will work.
  4. Does the settings.py (or anything it imports like "from localsettings import *") include CACHE_BACKEND?
  5. What happens when you restart apache? (e.g. sudo services apache restart). If a restart clears the issue, then it might be apache doing caching (it is possible that this could also clear out a locmen Django cache backend)
John Paulett
I agree. It's probably Apache or your ISP doing the caching.
Paul McMillan
1. The site is currently running on a server on our local network, so there is no proxy.2. MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware',)3. None of those terms appear anywhere in the code.4. No5. Restarting Apache does clear the issue and refreshes the cache at a new value
Travis
A: 

Are you using a multiprocess configuration for Apache/mod_wsgi? If you are, that will account for why different responses can have a different value for the timer as likely that when timer is initialised will be different for each process handling requests. Thus why it can jump around.

Have a read of:

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

Work out in what mode or configuration you are running Apache/mod_wsgi and perhaps post what that configuration is. Without knowing, there are too many unknowns.

Graham Dumpleton
httpd -V shows the Prefork MPM is being used. threaded: no, forked: yes (variable process count)
Travis
Then separate requests can be handled by different processes and so those processes may have distinct views of data. Also read 'http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html' for dangers of using prefork with mod_python and mod_wsgi.
Graham Dumpleton
That seems to be what is happening. I changed the configuration to run in Daemon mode, limiting the number of processes to one, which has limited it to only one cached version of the page. So my timer resets to the same value on every request. That's unfortunately still not the desired behavior though.
Travis