Eric Stevens On CFContent And Memory Usage In ColdFusion 8
Posted May 14, 2008 at 6:02 PM
This is just a minor note but a really powerful piece of information. Eric Stevens of the B And E Blog did some memory usage testing involving ColdFusion 8 and the CFContent tag and the findings are very cool:
I just did a test in CF 8 using FusionReactor to watch memory while using <cfcontent type="application/x-zip-compressed" file="#ExpandPath('bigfile.zip')#">
Memory was at 141mb when the file started, memory was at 151 when the file transfer completed. The file was 302 meg, and the transfer took about 2 minutes. The memory graph never spiked, and never went over 151 meg, though it did clearly do a garbage collection in the middle of the transfer and drop down to 141 meg before rising gradually to 151 again.
Long story short: it looks like <cfcontent file="..."> uses buffering to transfer the file, it doesn't consume an inappropriate level of resources.
Not to reiterate what he just said, but it looks like our assumptions were wrong - ColdFusion's CFContent tag is being smart about the way it reads in and streams file data to the client browser. Clearly, memory usage should not be a concern when it comes to the use of CFContent to stream secure files out of a document library. And, as I have been told before, tying up the thread to stream the file is not much of a concern either; I have no real evidence about the thread usage one or the other, so I just have to go with what I have been told.
Based on the evidence and hearsay, ColdFusion's CFContent tag is nothing but totally awesome and should be used whenever necessary. Or is that too big of a leap in faith?
Comments (6) | Post Comment | Ask Ben | Permalink | Print Page
Ask Ben: Working With Lists In An Object Oriented Programming Application
Using ColdFusion To Stream Files To The Client Without Loading The Entire File Into Memory
Reader Comments
This is good to know, thanks.
Then one last vice of CFCONTENT may then be the confirmed(?) issue of throttled transfer speed?
Back in the day there had been lots of discussion about slower download speeds when using CFCONTENT.
I'm not sure I ever saw this disproved or fixed or what though, but it always made me feel a little dirty when using CFCONTENT to secure file access. Perhaps someone can shed the light on this.
cheers, .brett
Posted by Brett S on May 14, 2008 at 7:19 PM
It might be slightly unrelated to the original test, but what happens under load?
2 concurrent, 5 concurrent, 10?
The stand alone test proves a point, but in the real world, does that hold up?
Posted by Brian on May 15, 2008 at 11:01 AM
That's a good point Brian.
Just now I did 5 simultaneous requests, and the only impact I noticed was increased CPU usage (ProcessExplorer had it almost all in disk IO, probably from me simultaneously reading and writing hundreds of meg to my disk under a VM environment). The only impact on memory seemed to be the climb & garbage collection was a little faster (not even 5x as frequent, maybe only 2x as frequent).
Posted by Eric on May 15, 2008 at 11:32 AM
@Eric,
So, if there was any performance issues, it seems that this would be result of the file system, not necessarily with CFContent. Meaning, that you would see load issues on any server side scripting language because it seems the file reading and the bandwidth becomes the limiting factor. Does that seem correct?
Posted by Ben Nadel on May 15, 2008 at 2:33 PM
Yes. And further, I believe that I only saw this much CPU usage because I was working my disk much harder than the server would (I was reading off the same disk drive as I was writing files to, all from within a virtual machine - which has reduced disk performance to begin with).
CF's CPU time was around 15-20%, the rest was consumed by 5 copies of WGet, all of these processes showed high IO time in Process Explorer. These are similar characteristics to what my CPU looks like when I bypass CF and download the files directly from the server.
Posted by Eric on May 15, 2008 at 2:40 PM
@Eric,
Rock on. Do you realize how cool your findings are??
Posted by Ben Nadel on May 15, 2008 at 2:48 PM
