support caching of compiled Template Toolkit templates

Bug #1449709 reported by Galen Charlton on 2015-04-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Template Toolkit supports caching compiled templates on disk -- and testing shows that enabling this can result in a roughly 15% decrease in the time it takes an Apache backend to load a template for the first time.

For example:

time curl http://localhost/eg/opac/record/1
without caching compiled templates: ~3.6 seconds
using compiled template caching: ~3.0 seconds

A patch is forthcoming that will allow enable caching of compiled templates.

Evergreen master

Galen Charlton (gmc) on 2015-04-28
Changed in evergreen:
importance: Undecided → Wishlist
tags: added: performance tpac
Galen Charlton (gmc) wrote :

A patch is available in the user/gmcharlt/lp1449709_cache_compiled_templates branch of the Evergreen working repository:;a=shortlog;h=refs/heads/user/gmcharlt/lp1449709_cache_compiled_templates

tags: added: pullrequest
Mike Rylander (mrylander) wrote :

And here's a follow-on branch that incorporates Galen's changes as well as template processor persisting for even more speed. From the commit messages:

   LP#1449709: caching compiled Template Toolkit templates

    This patch enables caching of compiled Template Toolkit
    files on Evergreen web servers, which can provide a modest
    improvement in the time it takes (say) TPAC to render
    a page, particularly by a fresh Apache backend.

    This is controlled by a new Apache virtualhost variable,
    OILSWebCompiledTemplateCache, which can be set to a
    directory on the webserver for storing compiled templates. This
    is enabled by default for new installations.

    This patch also adds OILSWebTemplateStatTTL, which can be
    use to tweak the STAT_TTL Template Toolkit setting. Note this
    bit anticipates future work to also cache TT objects, so
    at the moment, setting OILSWebTemplateStatTTL has little effect.

    Finally, this patch also fixes a bug where attempting to
    disable OILSWebDebugTemplate would result in internal server errors;
    it also sets the default value of this setting to false.


    LP#1449709: Persist template processor for speed

    By persisting the Template Toolkit processor object per
    vhost/locale/context-loader/xml-strictness instead
    of creating a new one for every request, we allow TT
    to maintain an in-memory cache of all the templates it
    has compiled. This increases speed by as much as 80%.

    In addition, we reduce the number of times the TPAC checks
    for the existance of a template by remembering the state
    of the first readability probe. This is most important
    on systems where the templates are stored on NFS, where
    stat(2) system calls can be particularly expensive.

    We now pass the Apache object ($r) to the template processor
    instead of relying on tied-STDOUT behaviour, because each
    request gets a new tied file handle. After the first one,
    it's the wrong one.;a=shortlog;h=refs/heads/collab/miker/lp1449709-TT-caching-squashed

Galen Charlton (gmc) wrote :

I've tweaked the commit messages and added release notes, so the patches for the pullrequest are now the three at the tip of the collab/gmcharlt/lp1449709-TT-caching-by-egweb branch in the working/Evergreen repository.;a=shortlog;h=refs/heads/collab/gmcharlt/lp1449709-TT-caching-by-egweb

Galen Charlton (gmc) on 2015-05-07
summary: - support caching of compiles Template Toolkit templates
+ support caching of compiled Template Toolkit templates
Mike Rylander (mrylander) wrote :

I've pushed a commit to this to fix an issue with cache mapping (thanks, oils://). From the commit message:

EGCatLoader overwrites $ctx->{hostname} when serving the staff client
version of TT-generated content. This is bad for us because we use
that as part of the TT Processor cache key. Instead, we'll just
always ask Apache, via $r.

The following related branches will need to include this commit as well:


Galen Charlton (gmc) wrote :

I've merged that patch into the two related branches mentioned in Mike's 2015-05-22 comment.

Changed in evergreen:
assignee: nobody → Josh Stompro (u-launchpad-stompro-org)

Hello, I tested this out on master as of 6/9/2015.

It seems to just work, I did several measurements with curl before and after and there is a definite improvement in load times with these changes. It would be better to do some longer term testing and graph it all out, if I find time I'll plug it into zabbix to graph a days worth of latency before and after the patch.

Without caching
real 0m2.021s
real 0m2.152s
real 0m2.320s
real 0m1.586s
real 0m2.117s

With caching
real 0m1.738s
real 0m1.935s
real 0m2.000s
real 0m2.065s
real 0m1.829s
real 0m0.964s
real 0m1.724s
real 0m0.916s
real 0m0.928s
real 0m1.663s
real 0m1.172s
real 0m0.969s
real 0m0.914s

The only oddity I noticed was that I couldn't get LP#1435938 "Allow Staff to clear Added Content cache" to work, but I really don't know if that is related to my test system or to some interaction with this. It worked fine on the sandbox setup to test it. And it still doesn't work when I disable the caching by commenting out "PerlSetVar OILSWebCompiledTemplateCache" in eg_vhost.conf. So it probably isn't related.

I have tested this code and consent to signing off on it with my name, Josh Stompro and email address, <email address hidden>.

Changed in evergreen:
assignee: Josh Stompro (u-launchpad-stompro-org) → nobody
tags: added: signedoff
Bill Erickson (berick) on 2015-06-10
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

I didn't do any timing, but can confirm the code creates cached templates and generally runs without issue.

Bill Erickson (berick) wrote :

I'll merge soon unless anyone shouts NO.

Changed in evergreen:
status: New → Confirmed
Bill Erickson (berick) wrote :

Merged to master. Thanks, everyone.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
status: Confirmed → Fix Committed
Bill Erickson (berick) on 2015-06-10
Changed in evergreen:
milestone: none → 2.9-alpha
Changed in evergreen:
milestone: 2.9-alpha → 2.9-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers