Cache templates

A couple of calls I've made in the patch:

• Templates are only cached while DEBUG is False (because if you're testing, you don't want caching getting in the way of your latest templates).

• CACHE_TEMPLATES defaults to 600. I originally had it set to 0 (i.e. off) but I thought that people may as well benefit from it. I'd be just as comfortable with it being off by default.

Oh, and there's a comment in the patch saying "(Python 2.3 can't pickle any filter decorated with stringfilter)", since my understanding is that this will work in >2.3 after of the #5701 patch is applied.

Can you please drop in some details of the performance testing you did for this. In the past, the reason template caching wasn't done is because for real world applications the speed up wasn't that significant, when measure in terms of total request time.

a small app to test speed

Ok, I've attached an app which I added to the end of a smallish project I'm working on.

The tests use the test client to get the response, so I guess that's somewhat close to total request time. The matching url uses the direct_to_template view to display a simple template (which inherits a simple base template). The client runs 1000 gets uncached (to warm up the drive), then times 1000 cached vs 1000 uncached requests.

Granted, this is testing on a laptop with slower drive speeds than your average server, but still there is a notable difference between speeds (even with simplistic templates)

WARMING UP TO TEST FOR CACHE TEMPLATE SPEEDS
CACHED TEMPLATE...   3.9408
UNCACHED TEMPLATE... 4.4971

(this is just testing with the default locmem cache, by the way - I'm not sure if other ones would be faster or slower)

This seems to be just cacheing the body of the template file - why would this be any better than relying on the OS's underlying buffers? It might make more sense to check real-world profile data to see how much time is spent parsing, rather than reading, the templates.

Replying to jim-django@dsdd..org:

... how much time is spent parsing, rather than reading, the templates.

It's caching the result of get_template_from_string(), which as far as I can tell is the compiled template.

I've benchmarked our applications with and without this patch. With the patch we deliver about 25% more pages per second than without.

Related ticket: #9154

I've benchmarked this with an app that uses full view caching, and it seems to be the cause of a large performance DEcrease :( I'm not sure why, but without this patch I get 900page/second (using ab), with it almost halves.

Could be something to do with the caching backend you're using (since this patch uses Django's caching). I don't really see how it could slow it down that much though - after the initial template cache, it should be returning your full cached view.

I find it hard to see how a one time cache can cause an ongoing half in your views if they are fully cached.

We are using memcache as the backend. I haven't had time to check it out fully yet, but it seems like it's when 'cache' gets imported on line 24 there is some work going on which slows down the response. I'll investigate further and report back.

Re-written BlockNode? and ExtendsNode? to not update nodelist in render()

See loader_tags.diff for some changes to support caching of templates which use {% block %} and {% extends %}.

Caching only works if tags do not change their attributes in render(). render() should only set local variables and perhaps alter context. #7501 (cycle tag) will also cause problems if templates are cached

I'm not sure which of the several "template caching" issues is the best to comment on. See also #9874 #9154

Notes on loader_tags.diff:

• store block relationships in context rather than template nodes
• build block dictionaries at template parse time rather than render time
• always use get_template to load templates (not find_template_source)
• a special block_context object is placed at context['block'] to support block overrides and {{ block.super }}.
• TODO: reduce visibility of block_context
• TODO: #7501

cainmatt, could you please post any speedups (in %%) you notice? Thanks.

As mentioned before, #9874 and #9154 are duplicates. Closing them in favour of this one. Both of them have patches which may or may not be useful.

revised loader_tags.diff, fixes IncludeNode BlockContext handling

revised loader_tags.diff, reset BlockContext in !Template.render()

Vadim,

It would be best for you to test speedups on your own application. Normally template parsing would only be a small part of overall application time (~<20%).

The loader_tags.diff changes by themselves would not result in a speedup. They are necessary but not sufficient for caching templates.

I have implemented a very simple dict lookup in template.loader.get_template() similar to #9154.

The reason I wanted to cache templates is that I have custom tags which do some processing during parsing which I don't want to repeat all the time.

A very rough test of one of my pages yielded: Requests / sec 18 Django-1.0.2 24 template cache on (33% improvement)