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

Reply via email to