Look at that hit rate! That isn’t unusual, a 75% hit rate for cached elements in a well designed system. That cache page is copied from an e-commerce site undergoing testing for a couple hours, by the way. Most of the caching is from presentation stuff, such as menuing and page widgets.
I think that the incredible hit rate goes to prove that for most any real application, you should be thinking about caching sooner rather than later. Build it in. It is not “premature optimization” to design it up front.
The background of that screenshot
For my Django apps, I use a cache manager application I wrote in a brainstorm fugue state a couple months ago. I really needed it for my still-in-testing InvisibleCastle gaming site rewrite, since I do so many lookups and repetitive viewing of the same information.
Once I’d written and debugged it — which took longer than I’d have liked, of course — I started using it as a matter of course in all my client projects. Then last week I had another brainstorm and actually wrote a quick set of management pages for it. Now I can observe the cache in operation, clear it, or even a subsection of it. It has been invaluable, and I can see the vast increases in speed it affords my apps by simply comparing the performance with and without the cache running. I haven’t run formal trials, but it feels at least twice as fast, probably more.
Technorati Tags: django, caching
5 responses so far ↓
1 john speno // Aug 22, 2007 at 5:10 am
There’s a feature I like in the e-commerce app I’ve been using for the past few years. It allows us to build a static version of the site with all the pages written out to disk. That makes things as fast as possible. Is that something that django has been made to do yet?
2 Bruce // Aug 22, 2007 at 7:26 am
Hm. Somewhat, I suppose. You can choose to use a file cache and give it a long timeout. But I don’t think that is quite what you mean.
You are saying that your package can write out a set of static pages and they’ll work with no dynamic backend? If that’s the case, then no.
I personally wouldn’t use such a feature except in rare cases. The store needs to be dynamic, not only on the front-end, but on the back, tracking inventory, referrers, and providing access to the admin pages. A static set of pages would be only useful as a generator for a PayPal cart or something similar.
3 john speno // Aug 22, 2007 at 8:37 am
Yes. It writes out static pages like product_one.html with links to static images on disk etc. Any part that needs to be dynamic still is (e.g. the cart and admin interface) and it’s more than just a PayPal frontend.
For a small store it’s quite nice, but I imagine it wouldn’t scale well for larger stores that would need to rebuild their static pages frequently. We do it only rarely and it only takes a few minutes to build just over 300 static pages. On a dedicated server I probably wouldn’t even bother.
4 Fredrik // Aug 23, 2007 at 3:40 am
“Is that something that django has been made to do yet?”
Why not just use “wget –mirror” against a staging server, and a suitable apache configuration?
5 john speno // Aug 23, 2007 at 6:17 am
Brilliant! Tack själv.
Leave a Comment