I started writing responses to all the great comments I got from my last post, but those rapidly grew so large and… ummm… tangled that it just seemed more manageable to just write a new post to address all of them!
Simon raised concerns around the behaviour of the “save class files to disk” setting for sites with a large number of templates. All I can say is that once disk drives and file systems start functioning as efficiently as processors and memory, this shouldn’t be as much of a problem. For now, I agree with Simon - if your file system is running slow trying to locate compiled templates (I assume this would be the issue with a large number of files in a single folder), then you might as well let your processor and memory do all the work and compile templates, rather than attempt to retrieve compiled templates from the file system. Then again, if you’re dealing with large, complex templates, retrieving a compiled template from the file system might be faster than compiling on the fly. I’m not sure what the guidelines around this should be (Simon suggests switching off save class files at 5000 templates and over), but I would suppose it would be extremely dependent on hardware. It would be best to benchmark your systems with various combinations of settings, and see which works for you.
Bob asked how a live environment could be updated if the the trusted cache setting was switched on. The simplest way to do this would be to push your new templates in, clear all class files under wwwroot/WEB-INF/cfclasses, and then push the “Clear Template Cache Now” button on the CF Administrator (under Server Settings > Caching). This will force the new templates to be compiled and loaded into the cache.
Given both Simon’s and Bob’s comments, I got curious as to how our web team manages deployments to the Adobe website. Vijay Shah, who used to work on the CF engineering team, manages the group here. This is what he had to say:
The Adobe site is run on a cluster of servers, all of which have the trusted cache switch turned on. Every time a new version of the site is to be deployed, the servers are brought down one at a time, the new set of precompiled templates pushed in, and then restarted.
Note that the web team pushes out precompiled templates to the production servers. This is another technique that you could adopt if you want to save the one-time cost of compilation in production environments. This is especially important for servers that function under high loads - when a server is restarted and brought back into the cluster it will brought under load very suddenly. The cost of simultaneously having to compile a large number of different templates due to sudden load could bring a server to its knees! In case you’re wondering how to precompile templates, see the documentation for cfcompile here.
Claude asked about how these settings could affect multi-instance deployments on Linux. The template cache is maintained as an in-process memory cache, one per instance. The settings I described should have the same effect on a multi-instance deployment as on a standalone deployment. Less compilation and less file I/O will always improve your server performance. The Adobe web team’s approach to deployment and Simon’s comment should give you some ideas for managing your own servers. In fact, pushing in precompiled templates might have an even greater effect on a multi-instance deployment - individual instances would no longer have to do compilation themselves, and so the performance of the cluster as a whole should go up.
Charlie pointed out that the template cache pops/sec statistic is available via the cfstat tool. While cfstat is a great utility, I much prefer my own tools… ;-) Damon and Jason will have my head if I say any more now - but if you’re coming to MAX, I can promise you an interesting show. Perhaps not one that to rival the attractions of Las Vegas… unless, of course, you’re a die hard CF-er!
Last, but by no means least, thanks to Phillip for asking about email subscription (though you really should get a feed reader) - turns out the nice folks at FeedBurner provide this service free of charge. For those who’d like to get email for new posts, sign up using the “Get Email” box on the sidebar off the main page.
Steve House | 13-Jul-06 at 11:10 am | Permalink
What class will you be teaching at MAX where you will demo your tools?
ashwin | 13-Jul-06 at 11:16 am | Permalink
The names aren’t final yet, but I should be handling the Unlocking the ColdFusion Server Black Box session.
Bob Everland | 13-Jul-06 at 1:05 pm | Permalink
I’m on CF 6.1 and don’t see a “Clear Template Cache Now” button, is that for CF 7 and above?
ashwin | 13-Jul-06 at 2:36 pm | Permalink
I’m afraid so, Bob - it was introduced with CF7. You will need to do a restart under CF6.x.
Bob Everland | 13-Jul-06 at 2:45 pm | Permalink
Are compiled templates unique for each server? For instance if I compile the site on my dev server could I copy those compiled files to my live box (obviously the paths would have to be the same, which they are). Keep in mind I am on CF 6 and not CF 7 so I can’t take advantage of the -deploy option.
ashwin | 14-Jul-06 at 10:28 am | Permalink
There’s no unique server information embedded in compiled templates. However, a compile without the -deploy option will only compile source files out to the WEB-INF/cfclasses folder. The best thing to do might be to copy source for all your templates over to the production system, run cfcompile there, and then bounce the server. hth.
John Edwards | 18-Jul-06 at 10:04 am | Permalink
Is there anyway exclude a specific file/folder from the template cache? We have some templates that are re-generated every 3 or 4 minutes that stop us enabling template cache.
ashwin | 18-Jul-06 at 10:14 am | Permalink
Sorry, John, it’s all or nothing. But why would this stop you from enabling the template cache? Enabling the cache would still provide benefits for the rest of your “static” templates. Out of curiousity, what’s the situation where you need to keep regenerating templates?
John Edwards | 18-Jul-06 at 12:22 pm | Permalink
We have various financial news, stock price, and market commentary feeds that take some time to query at run time. So we built a back-end server running scheduled jobs every few minutes to generate about 70-80 hmtl “snippet” files, which are cfincluded into our cfml web pages.
This speeds up page execution, and reduces the number of queries on our financial news and stock price servers (who also charge a fee on each hit - 2 cents a hit really adds up on one or two million pages per week… ;-).
Enabling template cache stops cfmx picking up the modified html files.
It’d be real nice if there were a cf processing directive we could add to each template we didnt want cached.
ashwin | 18-Jul-06 at 2:04 pm | Permalink
Nice use case, John! I’ll pass the word on about a possible “cache-me-not” processing directive; I can see how that might be useful. It did occur to me though that there is a solution to your problem which would allow you to enable the template cache - cache the HTML snippets in memory (maybe the application scope?) and dynamically include them into your CFMs. Every time you generate new HTML snippets, force a reload of the snippet cache. Would that work for you?
Ryan Guill | 18-Jul-06 at 2:16 pm | Permalink
Periodically we have a situation that involves the caching of files that we can’t figure out completely. It came up this morning in fact and was wondering if you had any insight. We can hit a page and it will come up fine, then if we delete the page, we get a 404, handled by coldfusion, as we would expect. What is strange though is that if we put the page back, we continue getting a 404 through coldfusion for some reason. Two things will fix the problem that we have found, we can either change the file size of the page by putting a bunch of extra whitespace at the end of the file, or we can use the clear template cache button.
At first we thought it was an IIS issue thinking the document was 404′d when it really wasnt and relaying that information to cf, but it seems that it is on the cf end of things since the clear template cache button fixes the issue… What would be causing coldfusion to hang onto that 404 and not check for new versions of the file? It seems to be pulling in updates to other files as we make changes to them fine… and trusted cache was not enabled. It is an infrequent occurence, but when it happens whe always seem to spend quite a bit of time figuring out what is happening. Any Ideas?
Bert Dawson | 19-Jul-06 at 11:18 am | Permalink
With regards to a “cache-me-not” directive, would a work around be to turn off trusted cache, cache the changed template (i.e. cfinclude it), then turn trusted cache back on.
This is possible using factory RuntimeService.setTrustedCache(), but is it a good idea?
ashwin | 20-Jul-06 at 7:43 am | Permalink
Bert - you could do that, but you’d have to make sure that the changed pages were hit at least once so that they get recompiled and loaded (perhaps a CFHTTP call) before turning trusted cache back on again. Another approach might be to again dynamically include the HTML snippets by simply reading them off the file system (no in-memory cache), and then use CFCACHE on the CFM with a timeout equal to the time between regenerations of the HTML snippet files. You could then still keep trusted cache on, and get (potentially!) huge performance benefits.
ashwin | 20-Jul-06 at 10:24 am | Permalink
Ryan, I’ve been unable to reproduce the behaviour you describe. What version of CF are you running? Is there anything special about the template that goes 404? I would suspect that all that the extra whitespace is doing is forcing a file write so that the timestamp gets updated.
Ryan Guill | 20-Jul-06 at 12:13 pm | Permalink
There doesn’t seem to be anything special about the pages. We are currently running cf 7.0.0, but we have plans to update to 7.0.2. I think you are probably correct with the updating of the timestamp, I had thought that it also could be that we are changing the size of the file which is forcing cf or IIS one to notice that it is an updated file.
Im not surprised that you couldn’t reproduce it, I can’t reproduce it myself intentionally, it just seems to happen periodically.
Bert Dawson | 21-Jul-06 at 9:45 am | Permalink
Ashwin, with regards to turning on and off TrustedCache programatically, when i say “…but is it a good idea?” I mean in terms of server stability.
Is this sort of use of the factory supported?
Would you foresee any problems in switching this off and on in a production environment say every five minutes?
ashwin | 21-Jul-06 at 10:08 am | Permalink
Bert, toggling the trusted cache switch every 5 mins should be ok. However, keep in mind that you will pay a cost (shouldn’t be too large) in terms of some cache reinitialization on every toggle. 5 mins does seem a little extreme though - what’s your scenario? Oh, and as I noted in an earlier comment, remember that you will need to make actual requests to any changed templates for them to be recompiled and loaded into the cache while the trusted cache flag is turned off. Simply toggling the flag will have no effect.
In general, it’s preferred that you use the Admin API - runtime.cfc provides a setCacheProperty() function for this purpose - that is the supported mechanism… which is not to say that invoking the factory method will not work, just that it’s not officially supported.
Bert Dawson | 21-Jul-06 at 11:40 am | Permalink
The situation is that I store “labels” as structures in cfm files. The labels are editable via an admin front end. On a page which needs labels, the apropriate cfm page is included, and the labels displayed appropriately (all via functions).
The sites are also multi-lingual.
By labels, i mean the sort of thing which is normally hardcoded in the template. e.g. In this comment form there’s a heading “Post a comment”, a sentance about “your email is never published…”, then all the labels for the form fields. They would each be separate labels.
I can’t just store the labels in memory since it is possible to have runtime variables embedded in the labels: e.g when editting myLabel in myTemplate, an admin user could enter:
“the time is ”
which gets saved to the cfm file as:
myTemplate.myLabel = “the time is #labelOutput(’theTime’)#”;
So currently I can’t turn on trusted cache because it would mean any changes made to the labels will not get picked up.
But if i can save the .cfm file, turn off the trusted cache, invoke the saved file (probably via an include in custom tag to give it its own scope), then turn trusted cache back on, all in a supported way, i’d be laughing.
And presumably while trusted cache is turned off, i will be no worse off than i am currently: CF won’t need to re-initialise the whole cache will it? It’ll just be the files which are hit while caching is off, and even then CF will just be doing the same “has it changed” check that it does when trusted cache is turned off permenantly, right?
Bert Dawson | 21-Jul-06 at 11:42 am | Permalink
middle section in previous post should read:
I can’t just store the labels in memory since it is possible to have runtime variables embedded in the labels: e.g when editting myLabel in myTemplate, an admin user could enter:
“the time is <label_output theTime>”
which gets saved to the cfm file as:
myTemplate.myLabel = “the time is #labelOutput(’theTime’)#”;
ashwin | 21-Jul-06 at 11:59 am | Permalink
Yes, CF will still do the “has it changed” check, reinitialization is not for the templates in the cache, just for some odd bits of config that stick out of it.
I think there is an easier way out though… I’ll play around a bit and post something up shortly.
ashwin | 21-Jul-06 at 4:30 pm | Permalink
Ok, so the solution is simpler than my befuddled end-of-week head could come up with earlier… could you just stick the label strings in a property file, and then use evaluate() on them from your templates? That all depends on performance, of course; depending on how many labels you have, what you’re doing right now might indeed be the best approach. More arguments in favour of a cache-me-not directive.
Stake Five :: WHENTO: Evaluate() and Iif() | 24-Jul-06 at 11:51 am | Permalink
[…] Bert brought up a rather interesting scenario where he needed to force templates to be reloaded into the template cache, since he was generating bits of CFML code at runtime. I suggested that he might also want to take a look at the evaluate() function, since that would probably allow him to solve his problem in a simpler manner. […]