Andy Lester wrote:
On Jul 1, 2005, at 4:25 PM, Tim Tompkins wrote:
I'm just getting into TT and have the same concern. Looking at
Template::Provider, it appears that $Template::Provider::STAT_TTL
could be set to something arbitrarily large to avoid excessive stat
calls.
What exactly is "excessive"? How expensive are your stat calls? Are
you measuring, or just assuming that "stat calls" = "server grinds to
a halt"? How much traffic are you getting that stat calls are the
bottleneck?
Actually we're talking about multi-million hits per-day, high profile
sites in a rather large cluster. This is definitely not pre-mature, it'
coming from 9 years of development, testing profiling, etc. We're just
looking at TT after having been running Mason for the past ~5 years. All
of the site code lives on a NetApp and millions of stats (don't forget
to add in stats for each "included" component) definitely have an
impact, especially so over NFS.
Perhaps though, a better term to use than "excessive" would be
"unnecessary." The very nature of our system (including internal
auditing and SOX compliance) requires that even the most minor revisions
be tested and approved before going live. And when they are taken live,
revised components are flagged in a file as having been modified.
Granted, this mod file must have its mod time checked frequently, but
that reduces stats to a fraction of what they would be compared to
multiple files included to serve a single request. So, if we're talking
about 4 million hits per day and an average of only 5 components
comprise the service of a single request, you have 20 million file stats
for files that generally do not change. This is definitely unnecessary.
My suggestion to the original post was merely in response to his
indication that revisions would require a server restart, and because no
one had offered any suggestions a week following his post.
When you start playing with caching, you're probably trading off cheap
time (server) for expensive time (programmer). There are few things
more frustrating, or more of a time sink, than a change made to a
template file that "doesn't work" because TT was using the cached copy
of the file, and the programmer keeps flailing at the source file
wondering why his code is wrong.
Been there, resolved that once. Thankfully, we've come quite a way from
the flailing hands routine. I was hoping to find a reasonable resolution
with TT if anyone has already been down this road.
Premature optimization is the root of all evil, and unless you're damn
sure those stat calls are costing you, don't mess with the TTL.
Agreed (Knuth's maxim, of course), but please don't assume that everyone
who is new to TT is new to everything. Hopefully I've expressed my
position sufficiently that anyone who might have dealt with this before
and has a viable solution to lend a suggestion.
--
Tim
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
