The World's Favorite Open Source GPL J2EE CFML Runtime Engine

BlueDragon Developer's Journal

Subscribe to BlueDragon Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get BlueDragon Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open BlueDragon Authors: Reuven Cohen, Elizabeth White, Michael Sheehan, John Gauntt, Salvatore Genovese

Related Topics: Open BlueDragon Developer's Journal, ColdFusion on Ulitzer, Java EE Journal

BlueDragon: Article

Profiling CFML at the Tag Level, Finally!

Make short work of tuning

Tweaking and Tuning: Attempt 2
Again, take a look at the CFML and SQL in the display of Figure 5. If you could also look at the output of the page, you'd find it's a display of information about employees in a company. Hmm. If this isn't a big company, they probably aren't adding new employees all that often. Could it be that they haven't added one in hours? days? weeks? months?

This sounds like an excellent place to consider query caching. (Query caching was introduced in CF 4 yet many CFML developers still don't know about it. See Ben Forta's excellent introductory article from 1999, "Caching in on Performance", available at, as well as the Macromedia documentation.)

If you're new to query caching, you may worry that because the WHERE clause in the SELECT statement changes based on different incoming form data, that it may not make sense to do caching (you wouldn't want users to see the same data as a previous search for other employees). That's a common misunderstanding. The CFML engine (BlueDragon or CF) will cache based on each unique generated SQL statement. Again, see the docs for more information.

(Savvy developers may have noticed that the CFQUERY being analyzed also failed to use CFQUERYPARAM, where it used of form variables as the value to be searched in the WHERE clause. This could be both a security and an additional performance problem. But ColdFusion doesn't let you use CFQUERYPARAM in a cached query, so you'd have to choose one or the other. Clearly, you could test each approach to compare the performance improvement and then weigh the security concern against performance benefit. If you're using BlueDragon, though, I'm happy to report that you don't need to choose. You could do both, as it doesn't impose that limitation. But that's fodder for another article!)

So how long should we cache the results? Maybe there's a concern about keeping the display data up to date because the employee records can be edited elsewhere in the system. Even caching for just a short amount of time, like 15 minutes (or even a few minutes), can make for a performance boost. Again, we're in a perfect position to try it and see.

So I modified the CFQUERY to cache its results for 15 minutes by adding the attribute, CACHEDWITHIN="#CreateTimeSpan(0,0,15,0)#". I again cleared the profiler data and reran the load test. The results are shown in Figure 7.

Alright! We've made considerable progress. The personneldirectory/results.cfm request is not only listed once, but even that is no longer taking enough time to be highlighted by the filter. Indeed, we see only one remaining file that exceeds our filter. We could attack that next, but notice also that we see a whole new list of other page requests other than the results.cfm page, so clearly we've removed a significant bottleneck. We could also turn our attention to them. As is always the case, tuning is an iterative process.

Conclusion: The Profiler Made Short Work of Tuning
Clearly, the Profiler has been a powerful tool. It's made quick work first of identifying the longest running requests for a given period of time, then we were able to drill down to view the longest-running tag(s) within a given long-running request. Further, we could then drill down to view the uses of that tag across all files in that long-running request. Finally, we could even choose to look at the CFML source to view a selected long-running tag in context of its source.

It took a while to explain it all, but clearly in normal operation this could have taken just minutes to possibly identify and resolve a key bottleneck. This was a query problem, and I mentioned SeeFusion earlier which also has a powerful feature for specifically identifying query bottlenecks. I do recommend you check it out. Even so, I could just as well have found a problem with something other than a query problem. In any case SeeFusion wouldn't have targeted the specific line of code at issue. There's certainly a place for both tools.

If you're looking forward to this powerful profiling capability, I'll just remind you again that it's a BlueDragon-only feature, scheduled to be released later this year (the interface and feature set are subject to change). We already have ideas of still more profiling information we'd like to show (memory used for the objects in the page, and more.) Keep an eye on us.

The best place to learn about BlueDragon and its advantages is to visit the web site,, which has ample self-help information. To hear when the profiler is released, join the BlueDragon Interest list ( self_help/archive_search/index.cfm), a mailing list staffed by our engineers and customers.

More Stories By Charlie Arehart

A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor ( living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.