Using Text::Xslate as an alternative to Template::Toolkit?

David Marshall dmarshal at yahoo-inc.com
Wed Mar 7 22:43:28 UTC 2012




On 3/7/12 2:14 PM, "David Miller" <justdave at bugzilla.org> wrote:

> Byron Jones wrote on 3/6/12 11:29 PM:
>> Frédéric Buclin wrote:
>>> But someone replied to me privately that there is one possible
>>> alternative to TT, which is the Text::Xslate module, available on CPAN:
>>> 
>>> [...]
>>> 
>>> In mod_cgi environment, this module is only 1.5 times faster than TT,
>>> based on their benchmarks.
>> for bugzilla with mod_cgi those gains will probably be lost by the
>> overhead moose/mouse adds.
>> 
>> for mod_perl, we don't currently cache anything between requests; it may be
>> better to investigate retaining compiled templates across requests, as well
>> as looking into a backend (backed by mod_perl or memcached) for caching
>> generated html fragments between requests.
> 
> We do a lot of user-specific stuff...  gotta wonder how much of the
> caching is negated by the amount of data we throw at the templates which
> changes for every user that looks at it...

In our just-replaced version at Y! (a bastardized 2.22), we were using
memcached for a number of things because of the scale involved. I'll be
adding some of them back in as I observe what's going on with our shiny new
3.6.

Our bugs table changes very frequently, so one thing we did was to add
SQL_NO_CACHE to all of the queries that involved table bugs. We did want to
use the query cache for most of the other tables, so we didn't want to
disable query caching altogether. That's a very marginal performance
improvement, but it's non-zero.

We were using memcached to cache the rows from longdescs for a bug, keyed by
bugs.delta_ts. I don't recall any specific performance metrics, but our hit
rate was fairly good.

I've thought about caching all of the HTML for show_bug.cgi (again based on
bugs.delta_ts), but we put a "readable time" on bugs (i.e. "6 days ago").
One way to get around this would be to generate the HTML with tags that
either are replaced before being sent to the browser or that are computed
client-side. It should be noted that we currently don't employ any
particular group security, so everyone basically gets the same page.




More information about the developers mailing list