On Wed, 2009-02-25 at 16:42 -0800, saxon75 wrote: [...] > The culprits seem to be the for loop in the template that iterates > over node.article.tags and also the two calls to node.comment_count. > As you can see from the model, node.comment_count is a member function > that returns the value of node.comment_set.count, and it looks like > that isn't being evaluated until the template is rendered. > > What it looks like I need is to get my code to do more eager fetching, > but I'm not sure exactly how to go about doing that. Does anyone have > any thoughts?
Okay, there's loads of code here and I'm not really motivated to wade through it all. But what you're seeing isn't atypical behaviour. Your ultimate analysis seems fairly reasonable, though: if you're retrieving the same data more than once, you need to try and eliminate that, once you've determined it's the bottleneck. After all, if retrieving all the data takes 4 - 6 seconds, then retrieving it all in a slightly different order isn't going to improve things very much. It's still the same order of magnitude of work. What you really need to do is change (reduce!) the amount of data you're retrieving. At a minimum, that means trying to retrieve each piece of data only once (or as few times as possible). That might require changing the types of data structures you construct in your view, doing less automatic fetching in the template and more explicit organisation in the view (not a bad practice in any case). Further, you might want to look at caching some of the stuff that isn't going to change particularly often. Start at the top level: can you cache the whole page result so that the 4-6 second penalty is only paid every now and again. Lower down, can you cache the individual nodes or articles, since historical ones are unlikely to change particularly often? The benefit you get there depends on the frequency of reuse for each item, so depends on information you'll have to collect from analysing site usage. Three areas of API to look at there; the template "cache" tag, Django's view-level caching decorators, and the low-level caching API (for caching and retrieving in views). Coincidentally, I'm in the middle of writing a fairly long blog post on this type of optimisation. It's both somewhat case-by-case specialised, but also subject to some general rules (like reducing the amount of duplicate data retrieval). It's not a quick thing to write about, so I'm probably a few days away from publishing, but the above paragraphs give you the meat of the conclusions. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
