Using memcache can have benefits in many cases. However, as the sizes of your templates grow, the slower the response you'll get from memcache. In my testing I have seen that once you get to about 10k for a cached component, that local file based solutions become similar to memcache based conditions. Small results sets (less than 1k) are more ideal for memcache. Unless you have extremely small templates, you may hit similar performance issues. You may be able to get better performance by using a local ram basked disk for your cache.
And then this brings you to Perrin's point ... > I think what you're missing here is that there are two layers of > caching in TT. One is caching of compiling the template into perl > source code. This is what gets cached on disk. The other is > compiling the perl source code into a compiled perl subroutine > reference. This is what is separate in each process. There isn't much getting around the recompiling of the cached sub with TT2. If you use Template::Alloy however, the cached document (by default) is an arrayref data structure with no closures or hashes. This cached document will cache into memcache just fine. It will also read into memory more quickly (if cached using Storable) than pretty much any non-memory based caching system (I haven't found anything that beats Storable for read speed). The down side (among many I'm sure) is that Template::Alloy's load_template method isn't as well documented as it could be. You're best bet really is to follow Randal's suggestion of trying to precache the compiled templates in memory before Apache begins forking. Even if you adopt this, you should get some speed increase and memory decrease by using Template::Alloy and possibly Template::Alloy::XS. Paul _______________________________________________ templates mailing list [email protected] http://lists.template-toolkit.org/mailman/listinfo/templates
