The ability to view tag-level execution profiling (the amount of time spent on each tag in a request) is no longer a dream, and it opens up powerful new forms of debugging and performance tuning.

The Problem: Tools We Lack
Most CFML developers know that both ColdFusion and BlueDragon can be configured to show debugging info at the bottom of a page, which shows (among other things) the total time spent on a request and in each template within that request.

But how often have you wished you could see the time spent on each tag within the request? This would really help in determining where specific bottlenecks exist. While seeing that timing information for each individual tag would be powerful enough, we really need to start a higher level. What we need is a way to view all the requests against the server for a given time period, viewing their total execution time in aggregate, so we can identify just which requests are indeed the longest-running and therefore deserve our closer attention.

All these kinds of profiling/tuning tools have long been available to other developers, but not to us CFML developers. Users of BlueDragon, though, will soon have just this kind of tool in the BlueDragon CFML Profiler (scheduled to be released later this year), which has been designed to address this very kind of challenge.

Solving a Real Problem with the Profiler
Rather than just talk about the tool, let's instead dive right into using it to solve an actual problem. To help both identify the problem and confirm the result of code changes, I've used a load testing tool to run a small set of requests executing a subset of the Macromedia example applications that come with ColdFusion.

It's not important to discuss the load testing tool, nor will I bother detailing the particular requests I ran in the test. And I certainly don't mean to disparage the examples. They weren't written to be demonstrations of well-tuned code but rather very simple examples which beginning CFML developers could easily understand. Even so, they do represent rather typical practices that many developers employ which can hold up performance.

With the Profiler enabled, I ran a simple short load test to run through some of the example pages. (The details of how to start and configure the profiler may change between now and its final release, so I won't elaborate on how it's started now.)

The profiler is an extension to the BlueDragon engine, using a very low-overhead mechanism (aspects) to create a stream of profiling data available on a particular port, which can then be analyzed by a tool that retrieves the stream of profiling information.

Even though it's low-overhead and won't add much burden during profiling, the profiler can still generate a very large amount of information if enabled for too long a test (it's tracking every tag in every request while enabled). Profiling tools aren't really meant to be used to analyze full bore load tests. Again, I was just using a small sample generating multiple requests against several pages running for about 30 seconds.

The current version of the profiler is a web-based interface (HTML, generated from CFML), but a Flash-based version could be a powerful adaptation and is under consideration.

Viewing the Profile of All Requests
With the load test completed (or indeed even while it's running), I opened the web-based interface to view the requests currently being profiled. See Figure 1. The "get latest profiles" button caused the profiler to gather all the current profiling information being generated by the latest set of requests.

The profiler collects all the information since the BlueDragon engine has started, but I can clear the profiled requests at any time before running another set of tests, in order to focus only on those most recently run requests. I'll be doing this later, after performing some code changes based on the information presented from this first load test.

Since profiling may be generated for many requests (even hundreds in my small test), the interface provides for scrolling to show just 10 requests at a time. The list of requests can also be sorted by any of the available columns, and I have chosen to sort it by the "Render Time" column, listing the requests by total execution time per request.

Further, you'll notice that many of them are highlighted in yellow. That's not something I added to the screenshots for this article but rather it's what the profiler will do for you to help isolate the most troubling requests, based on a "filter" field available on the display. I've entered a value of 100 (milliseconds), but you can set it to whatever value you prefer depending on the kind of data shown in your profile display.

We can see that all the requests shown as being of greatest duration are for the page /cfdocs/exampleapps/personneldirectory/results.cfm. The load test ran many other requests, but these are the ones taking the most time, so that's where I can start to focus my tuning attention.

To be fair, the kind of information shown in Figure 1, viewing total time per request, can be obtained from other tools, including simple web server log analysis tools. Indeed, yet another tool offering this sort of aggregated CFML page request information (for both CFMX and BlueDragon/J2EE) is the excellent SeeFusion tool, available at http://seefusion.com.

Even so, there is at least one hint of the greater power of the profiler in that the display also shows the number of tags run within the request. Clearly that's not reported by a web server log analysis tool (nor even by SeeFusion, though it has great value as an adjunct to the profiler which I'll discuss later).

Drilling Down to View All Tags In The Request
At this point, most CFML developers would at least be delighted to be able to take this information and focus on the one page that's showing to cause the most execution time. They would open the code and start eye-balling to see what's up, but the BlueDragon Profiler can do much more for you!

You can click on a given request, and as Figure 2 shows it will drill down and view details for that request, displaying several interesting kinds of detail that CFML developers have simply never seen. First, notice that it displays all the tags that were executed in the request, and further it shows the number of times they were executed, how long they took in aggregate, as well as the average time spent per execution of that tag. Very cool!

Note as well that this information is across all templates executed within the request, meaning included files and CFML custom tags, whose names are all shown at the bottom of the display. That portion of the screen also shows how many times each of those files was used in the request as well as the number of tags in each file and the total time spent in each file.