So a few days ago I wrote a quick blog entry asking why more people weren't making use of Trusted Cache. While not a silver bullet, it can sometimes be a quick way to improve your site performance. A reader, johans, commented asking what the impact would be on files stored in the virtual file system (VFS). I assumed it would act the same - ie, any changes would not be picked up. Today I wrote a quick template to see if I was right:
<cfoutput>My number is #num#<p/></cfoutput> <!--- note, RAM mapping was made in cf admin --->
<cfinclude template="/RAM/foo.cfm">
<cfset num = randRange(1,9999)>
<cfset content = "<cfoutput>Your num is #num#</cfoutput>">
<cfset fileName = "ram://foo.cfm">
<cffile action="write" file="#fileName#" output="#content#">
When run, this code creates a random number and writes the CFML to display it to a file in the vfs. Yes, the code is dumb. There is no need to use cfoutput in this case. But I wanted to ensure I had some dynamic code in the VFS. After writing it, we output the number and include the template. Don't forget you can't cfinclude a file via a full physical path. I made a mapping in the CF Admin for my VFS called RAM and included it like that.
Before turning on trusted cache, I ran this template a few times and saw what I expected - the same number in both outputs. After turning on the trusted cache, the number in the VFS "froze" since ColdFusion wasn't picking up on the changed CFM. (Which is expected - this isn't a bug.) To be clear, ColdFusion is still writing the file out and changing it. That part works fine. It's just the compiled version of the CFM that is being cached and reused. Clearing the trusted cache immediately brought out the new number.
So what if you want to make use of the VFS like this and make use of the trusted cache? Well if we assume you aren't writing to a static file on every request, you can simply use the Admin API to clear it. If you do need something for every request you could consider unique file names. Just be sure to "clean up" or your VFS will fill up eventually.