Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
In my
previous entry, I explained how different features of the CF8 monitor have different levels of overhead. I also pointed out that there was value
even if you didn't enable any of the features at all. I can't stress that point enough. So yes, there "is" such a thing as a free lunch.
Some Cool Info: at ZERO COST
Even without pressing the buttons to start "monitoring", "profiling", or "memory tracking", you can see:
- how many pages are having errors, and details on each
- jvm memory used, and a detailed graph
- template cache status (how many pages, and total size of the cache), graphed over time
- query cache status (yep, the cached query count and total size)
- and more
Big deal, I may hear some say. Well, it is a big deal. That template cache and query cache status info is gold, and something that many of us have long lamented to have. Talk about opening up the black box. And with no overhead.
But wait (to quote the old Ginzu knives commercials from the 80's), there's more! And I mean, seriously cool info--again at zero cost.
Some Amazing Info! Again, at ZERO COST
Even without enabling ANY of the three buttons, you'll still be able to see all this really cool new info:
- active sessions (yes, a list of all sessions currently active, and if you click on each, the session variables and values currently assigned!)
- application scope memory usage (yes, as above!)
- server scope memory usage (yes, as above!)
- and more
All I can say is "wow". That is just so cool to get that, for free.
Don't we need to enable "memory tracking"?
I'm sure some are asking, "Well, isn't that what the 'start memory tracking' would be about?" Apparently not!
The help page for the monitor (the ? at its top right) describes the memory tracker as reporting "the queries and sessions that have used the most memory... and profiling information on the largest variables on the Requests by Memory Usage report". I'm willing to do without those in exchange for the info above, most of the time.
Now, on the other hand, the ellipses in my quote above (the "...") refers to where it also said the memory tracker provides "the memory usage of all application and server scopes". Hmm. Well, I'm seeing that without enabling it. Or maybe it's referring to some other aspect of the reports. There are indeed many reports in the monitor which had no data if none of the "start" buttons were enabled.
So what, then is the "start monitoring"?
As for the "start monitoring", according to the help it provides info on "active requests, slowest requests, active sessions, cumulative server usage, highest hit counts, template cache status, request throttle data, requests that timed out, requests with errors, and server alerts." Again, I'm not so sure about that. I'm seeing a few of those without using that feature.
I'll leave it to you to read what the "start profiling" says it enables.
I do think an argument could be made that the "start monitoring" button probably may contribute to confusion. I'm sure some will try to convey what I've written and talk about what you can get from "the monitor", and some will assume it's tied to enabling that button, when clearly it isn't. Maybe it could be called something else. Probably too late for that.
Joy in Mudville
So if you hear someone say, "we won't use the monitor in production", slap them roundly on the cheek...I mean, point them to this blog entry (and the last one). Seriously, it's tragic if someone would miss out on the value of the monitor simply because of an overinflated sense of fear.
But do have them check for any comments below, too. Maybe someone will correct me. Maybe my setup is somehow unique, but I've run many tests without these other features on and observed in real time the display of all the above.(And I have not had the "start" features enabled since I installed the RC a week ago, though I did have them enabled in previous betas. I can't believe that's having an impact.)
Finally, I'll point out that even if you don't want to (or can't for some reason) use the Server Monitor interface, you can get all the same information by way of the Admin API, and a new servermonitoring.cfc. Ray Camden's done a blog entry on it. Indeed he makes a similar observation about how he was able to get some of the methods to return data even if the docs said that a particular monitor feature must be enabled.
Check it out for yourself, and feel free to report here your corrections, or your delight. Hope that's helpful.
OK, I'm playing a little trick here, and it's the first time I've ever felt the need to do it in 
The CF Enterprise Server monitor is more powerful than many may realize, yet naturally some are immediately concerned about its potential overhead, especially if they're considering running it in production. Things aren't quite as obvious as they may seem, or as many may assert. 
