ColdFusion Article

ColdFusion 8 server monitoring – Part 1: Using the Server Monitor in development

Useful monitoring for development

With some details of using the Monitor covered, I'll turn your attention now to details that could be of particular interest during development.

Tracking shared scope memory utilization

One of the most challenging problems in ColdFusion development has always been knowing how much memory is being used in shared scope variables, such as session, application, and server. Prior to ColdFusion 8, developers generally had little clue into the impact of their use of shared scope variables, especially when considered in the context of a large number of requests for the application. The Server Monitor reports this detail, either for particular requests, or for all active sessions, all active applications, and more.

Despite appearances, you do not need to start memory tracking to obtain much of this sort of data on shared scope variables. Note that even without any of the "start" options enabled, you can view all active sessions (and details including the name, value, and size) using the Statistics > Request Statistics > Active Sessions report (as in Figure 4). You can view application and server variables in use using Statistics > Memory Usage > Application Scope Memory Usage (as in Figure 5) and Server Scope Memory Usage, respectively. While each of these show a "size" value of 0, if you drill down into each, the detail page shown lists all the variables, their values, and the size—all even if none of the "start" options are enabled.

Figure 4. Active Sessions report

Figure 5. Application Scope Memory Usage report

So how do these reports differ if you do enable one or more of the "start" buttons? With respect to these two reports, the "size" column will be populated if you enable both the "start monitoring" and "start memory tracking" features. While that's a marginal benefit for enabling the heavyweight "memory tracking" monitoring, that feature enables other very important information.

Track slowest tags or function calls

Perhaps one of the greatest benefits of enabling the ”start profiling” is that it allows you to track the slowest tags or function calls within a request. Recall the slowest requests detail page in Figure 3. With “start profiling” enabled, the section labeled “Top 10 Slowest Tags & Functions” will now be populated to show the tag or function name, the template path and line number from which it was invoked, and the time it took in milliseconds. If you select one of the lines showing that information, the “CFML Stack Trace” section below it will be populated with details about how this particular line was called from preceding templates in the request pipeline. All this information is incredibly helpful in development, when you're trying to understand the cost of various coding choices and to find bottlenecks.

Figure 6. Memory Usage Summary Report

Tracking largest variables in a request

When creating (and managing) ColdFusion applications, it can be vital to know how much memory is being used by each request—and to know in particular how that memory is being used among different scopes (variables, var, session, application, etc.) and by their type (query result, simple variable, etc.). Without this, it’s often a stab in the dark knowing where to begin tuning an application. One of the real gems of the Server Monitor is the Requests by Memory Usage report. Accessible with Request Statistics > Memory Usage > Requests by Memory Usage (figure 7), it lists the top requests (a number of your choosing) which exceed a given amount of memory (again, a number of your choosing). If you select one of the requests, you’re shown a detail page (figure 8) showing a breakdown of the top 10 largest variables in the request (by name, scope, type, template, and average/last size).

Figure 7. Requests by Memory Usage Report

Figure 8. Requests Memory Usage Detail Report

These reports require “start memory tracking”, which as stated above is the most expensive operation of all (in terms of overhead), and so should be used with caution. Still, even if enabled only briefly, and even for only your own requests made as a lone developer on your box, it can help you to understand the impact of your coding techniques. Of course, with load (whether simulated in development/test or by real load in production), you can obtain far more accurate and useful data about the impact of your choices.

Tracking JVM Memory Usage

Developers (and production admins) are often very interested in how ColdFusion is using the Java Virtual Machine memory that underlies ColdFusion. While various logging features could be enabled in ColdFusion to track this, or third-party tools could be used to visualize the use of memory, the Server Monitor now offers a graphical depiction of JVM memory usage. Accessible as Statistics > Memory Usage > Memory Usage Summary, it's shown in Figure 9:

Figure 9. Memory Usage Summary Report

Again, this is available even if none of the “start” buttons is enabled. If you enable memory tracking and monitoring, that same page also offers another chart (below that shown above) that tracks the amount of total memory used by each of the application, server, and session scopes.

Notice that there is a “Run GC” icon in the top left of this display. Clicking this will run the Java Virtual Machine garbage collector. This may be useful during development, but should not be relied upon as a solution to problems in production. Instead, the source of memory problems should be identified and resolved. Some of the other reports in the Server Monitor can assist with that effort.

Tracking cached queries

Until ColdFusion 8, we had no visibility into how many cached queries (CFQuery tags that use the CachedWithin or CachedAfter attributes) were being held in memory. But the Statistics > Database > Query Cache Status report now shows this information, and again it offers value even without any of the "start" buttons enabled, as the top portion of the chart (Figure 10) shows how many cached queries are in memory.

Figure 10. Query Cache Status Report

Note as well that the actual number of queries in cache is also depicted as a number at the top right of the chart, and at the top left is an indication of "Query Cache Hit Ratio." This percentage is very valuable, indicating how often requests for queries (using the caching attributes) did indeed find their query already stored in the cache. If that number remains low for an extended period with a production load, it means that the caching isn't providing much value, which could be for any number of reasons.

While that aggregate information is certainly better than when we had nothing, you probably will want to see still more detail, such as how often each cached query is requested (hit) versus executed (really queries the database). If you enable “start profiling,” you will find this information in the Statistics > Database > Cached Queries report (Figure 11), and if you double-click on a line in this report, you’ll be able to see the detail of each cached query, including its location (template and line number) and the SQL that’s cached, (Figure 12).

Figure 11. Cached Queries Report

Figure 12. Cached Query Detail

The monitor can even help you better understand ColdFusion operations. .For instance, did you know that multiple templates can share a single cached query, if the templates indicate use of caching and the CFQUERY attributes (most) are the same, and the SQL statement is identical, including line breaks? It's true, as discussed in the documentation on query caching. This Cached Queries report, however, will show only the first template that creates a given cached query result, even if other templates would reuse that cached result. If you click the refresh button (top right of the monitor) you can observe the hit count increasing on this page as you run other pages that share the same cached result.

There’s one gotcha related to the preceding Cached Query reports (not the Query Cache Status report): If you enable the “start” features after any query has already been cached, that cached query will not display on the report. To solve this problem, you can use the CFML tag with the action attribute of clear, cfobjectcache action="clear", which will clear the query cache so that future requests using the cached queries will display. Think twice about using this in production, if just to see this monitoring data. Clearing the cache will mean future requests must load the data from the database in order to repopulate the cache. The query cache will also be cleared when the cached queries expire or when the server is restarted next. If you'd like to know additionally the actual size of the cached queries (shown as zero in both of the preceding reports), you must enable "start memory tracking."

Tracking large, slow, and frequent queries

If you enable “start profiling” and “start monitoring,” you'll also enable the ability to track queries by their total execution time or their frequency of execution. If you add “start memory tracking,” you’ll also be able to track queries by their total memory used. These can help you find and focus on the queries you need to tune, which of course can be both useful and valuable if done during development.

You can reach the three reports, as Statistics > Memory Usage > Queries by Memory Usage (Figure 13), Statistics > Database > Slowest Queries (Figure 14), and Statistics > Database > Most Frequently Run Queries (Figure 15). In the first two of these screen shots, note that I've set the threshold value to zero to help produce additional data for this screen shot (which also means that the application shown is not a problematic one; it's just the one I was running at the time I took the screenshot).

Figure 13. Queries by Memory Usage report

Figure 14. Slowest Queries report

Figure 15. Most Frequently Run Queries report

For additional tuning techniques using the monitor, see the discussion of the Server Monitor in the ColdFusion documentation, as discussed in the final section below.

In this article, I've discussed just some of the many reports available in the ColdFusion 8 Server Monitor, with a focus on those most useful in development. In the future articles in this series, I'll focus first on more types of reports, especially ones useful for production, as well as the ability to abort troublesome requests. Then I'll discuss use of the multiserver monitor, as well as the alerts and snapshots features, and finally on miscellaneous aspects of using the monitor, including using the Admin API and various configuration settings for the monitor.

Where to go from here

Since online monitoring is a new feature in ColdFusion 8, the only substantial resources for learning more are the ColdFusion documentation. Since the Monitor is accessible from the ColdFusion Administrator (though it's technically separate from it), it's documented in the manual, Configuring and Administering ColdFusion, which like all the docs is also available online at the ColdFusion 8 LiveDocs site. Finally, note that there is also additional online help available within the Monitor, accessible using the question mark symbol (?) in the top right of the Monitor.

Check out the other parts of the ColdFusion 8 server monitoring series:

• Part 2: Using the Server Monitor in production
• Part 3: Automated monitoring and request management with Alerts and Snapshots
• Part 4: Multiserver Monitor, Admin API monitoring, and more

Page 3 of 3

Previous Page