On 4 February 2010 13:48, Tim Hoffman <zutes...@gmail.com> wrote: > Do you mean it parses all templates on instance startup. If so that > would be prohibitively expensive > if you have a lot of templates.
Yes. > And startup time (just processing all > the zcml, and all the other imports) is problematic as it is. > (In the project just compeleted www.polytechnic.wa.edu.au, there is > 131 template files. (page templates and metal macros). Our startup > time You can use the CHAMELEON_CACHE=1 environment setting to cache these. > for a cold instance without anything in memcache is between 4 and 8 > secs. If appengine is having problems then that can blow out a very > long way) It probably makes a lot of sense to memcache the templates, although memcache might decide to expunge the cached files since they won't be used much (only at startup). > Do you have any idea how much it costs to parse a template first time > round vs traditional zpt. Chameleon takes substantially longer than ZPT to parse and compile templates. > I am going to have to have a bit of play, but parsing all templates on > startup has me really worried. Memcache would alleviate that somewhat > but any new instance would then still have to check to see if every > template exists in memcache on startup and parse missing ones. > However the main problem with a memcache strategy on google is such > that anything can disappear from it at any time, which means if it's > gone from memcache then you would have to parse on use of the > template. Which sort of counters the whole approach. I wonder if the > datastore could > be used as a first line storage for the compiled templates. The they > could be loaded and then cached in memcache, that way the cost > would not be too high if the are not present as the loader could grab > them from the datastore. I thought just that, too. This approach might be good. Can you try it out? Other than that, perhaps it's possible to fool memcached. \malthe _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
