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.

OK, I'm playing a little trick here, and it's the first time I've ever felt the need to do it in 5 years of blogging (or 10, depending on how you count it). Anyway, I don't have any new content here.

It's just that I just noticed that the traffic for my 2nd blog entry on server monitoring was much lower than the first, yet it was posted about the time--and is just as important, if not more so for most people, than the first. So I've used a different title here to try to catch your attention. Looks like it worked! :-)

Please do go read the other, if you have still not. And let me know what you think, if you did. I'd also like folks to confirm what I'm seeing, as it seems almost too good to be true.

What's in a title? Everything, it seems

I can't help but fear that the title I used, "CF 8 Hidden Gem: Using the Server Monitor even without "starting" any collection...yes, TANSTAAFL", just confused people. "What's he mean by a collection?" And "TANSTAAFL"?

Actually, I wanted to say "Using the Server Monitor even without 'starting monitoring'", but obviously that would have been confusing, too. Indeed, I allude to this in the entry, about how the feature called "start monitoring" can lead people to think that the monitor doesn't do anything until you at least enable that. Not true, and that was the point of the entry! There's some amazing stuff "with zero overhead".

(Perhaps I also lost people with my play on the acronym, TANSTAAFL ("there ain't no such thing as a free lunch"), where I was referring to how there IS a "free lunch" here. Serves me right for being tricky. Again, I was scrambling to come up with a title because of the "start monitoring" challenge.)

Don't miss the features--truly hidden gems!

Anyway, the point is that if you're interested in the new CF 8 Server Monitor, whether for production user or not, you really ought to check out what I pointed out. I do think you'll be amazed.

Drop your comments on it over there, please. Not here. Don't want to create any further confusion! In fact, I'll disable comments on this one (another first).

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.

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.

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.

Update: I've updated this entry now 5 years later, in 2012, to give a bit more context to what I said originally. No change in the message, just a little more info and perspective. (There's also no change in the impact of it, pro or con, in CF 9 or 10.)

First, it's indeed true that depending on what you enable, it *could* be very resource-intensive and could even bring down a server under load. But conversely it also can have ZERO impact--yes, even in production. I'll discuss that in my next entry.

But before that, I just want to take a moment and explain the key 3 features that control what impact, if any, it will have.

Note that there are three buttons at the top of the monitoring page which "start" different monitoring features. (If you don't see these buttons, just refresh the browser again to get them to appear.)

So what are the implications of starting each of the optional monitoring features?

• start memory tracking: this has the highest potential impact for overhead, which can be very substantial, even to the point of crashing your instance. And even on a low-traffic developer machine, you might see a big hit from running this. More on this in a moment.
• start profiling: this has much less overhead. It primarily enables tracking of database activity. The help page for the monitor calls its overhead "minimal", but I will note that on a CF server with tremendous DB activity, its overhead could be more substantial.
• start monitoring: This is the least impactful button. It's needed to at least see running requests, as well as to have Alerts fire. But even on a busy server I've rarely seen it have a negative impact. That said, you don't need ANY of the 3 buttons enabled to see at least some info. More below.

Definitely check out that help page (from the front page of the monitor) or discussions in my 4-part series of articles on the monitor to learn more about what each button does as well as more about the monitor itself and its many features.

About the Memory Tracking feature

You'll note that I hedged above on the impact of the Memory Tracking. Conventional wisdom is that it is indeed a potential server killer, and I can confirm that I've seen it many times in my CF server troubleshooting consulting practice. But I can also report that I've seen it running on production machines and having virtually no seeming impact. I kid you not.

I suspect it has to do with how many objects are in memory, how complex they are, how busy the server is, etc.

Now, some might propose that you use it only for brief periods (minutes, seconds) to gather some info for analysis, perhaps only in emergency. (I even said this in my initial version of this blog entry.) But many have found that things go horribly wrong on some CF instances the moment it's enabled. So it's probably best not to use it at all on live prod server.

You might be able to do it in a test/dev server, and you may get value form that in looking at the impact at least of individual or small numbers of requests. But beware also that some problems simply don't present themselves except under load (and often only in production, not even with load testing), so using it in dev/test may not help spot/understand/resolve all problems.

So does that mean there's no value if you can't use this feature in prod? Well, no. Remember, this is one of 3 buttons. The other two have less overhead (especially "start monitoring"). More than that, you can get value from the monitor with NONE of the buttons turned on.

Any value if none turned on?

Yes, don't miss this vital point: there is value to using the monitor even with none of the start buttons enabled. That is deserves its own entry. Who says there's no such thing as a free lunch? :-)

So if you hear someone say "don't use the monitor in production", please make sure they're clear on all this. There are 3 features you can enable, or none at all, and each provides different info at different costs--some of it zero.

Postscript: The buttons stay enabled after closing the monitor, and even over restart

I know I've discussed this elsewhere, but while I'm updating this entry let me reiterate the point: it's vital that you understand that if you turn on any of these buttons, they STAY TURNED ON, even if you close the monitor. And EVEN IF YOU RESTART CF. In fact, this is important enough to deserve its own entry. I'll post that now (as I update this in 2012), CF911: Using the #ColdFusion Server Monitor? Be aware that the "Start" buttons remain enabled.