caching – Django Performance – Education Career Blog

I am using a django with apache mod_wsgi, my site has dynamic data on every page and all of the media (css, images, js) is stored on amazon S3 buckets liked via “http://bucket.domain.com/images/*.jpg” inside the markup . . . . my question is, can varnish still help me speed up my web server?

I am trying to knock down all the stumbling blocks here. Is there something else I should be looking at? I have made a query profiler for my code at each page renders at about 0.120 CPU seconds which seems quick enough, but when I use ab -c 5 -n 100 http://mysite.com/ the results are only Requests per second: 12.70 #/sec (mean) . . .

I realize that there are lots of variables at play, but I am looking for some guidance on things I can do and thought Varnish might be the answer.

UPDATE
here is a screenshot of my profiler
alt text

,

The only way you can improve your performance is if you measure what is slowing you down. Though it’s not the best profiler in the world, Django has good integration with the hotshot profiler (described here) and you can figure out what is taking those 0.120 cpu seconds.

Are you using 2 cpus? If that’s the case than perhaps the limitation is in the db when you use ab? I only say that because 0.120 * 12.70 is 1.5 which means that there’s .5 seconds waiting for something. This could also be IO or something.

Adding another layer for no reason such as varnish is generally not a good idea. The only case where something like varnish would help is if you have slow clients with poor connections hold onto threads, but the ab test is not hitting this condition and frankly it’s not a large enough issue to warrant the extra layer.

Now, the next topic is caching, which varnish can help with. Are your pages customized for each user, or can it be static for long periods of time? Often times pages are static except for a simple login status screen — in this case consider off loading that login status to javascript with cookies. If you are able to cache entire pages then they would be extremely fast in ab. However, the next problem is that ab is not really a good benchmark of your site, since users aren’t going to just sit at one page and hit f5 repeatedly.

,

A few things to think about before you go installing varnish:

  • First off, have you enabled the page caching middleware within Django?
  • Are etags set up and working properly?
  • Is your database server performing optimally?
  • Have you considered setting up caching using memcached within your code for common results? (particularly front pages and static pages displayed to non-logged-in users)

Except for query heavy dynamic pages that absolutely must display substantially different data for each user, .12 seconds seems like a long time to serve a page. Look at how you can work caching into your app to improve that performance. If you have a page that is largely static other than a username or something similar, cache the computed part of the page.

When Django’s caching is working properly, ab on public pages should be lightning fast. If you aren’t using any of the other features of Apache, consider using something lighter and faster like lighttpd or nginx.

Eric Florenzano has put together a pretty useful project called django-newcache that implements some advanced caching behavior. If you’re running into the limitations of the built-in caching, consider it. http://github.com/ericflo/django-newcache

Leave a Comment