Mike Brunt talks about “Tuning & Troubleshooting ColdFusion Using Native Tools” in this episode of the ColdFusion Alive Podcast, with host Michaela Light.
Mike is one of the speakers for the upcoming Into The Box ColdFusion Conference, where he will talk about Tuning & Troubleshooting ColdFusion Using Native Tools.
There are various tools and utilities which ship with ColdFusion and tend to be ignored when tuning is needed, also when trouble strikes. Server Monitor, for instance, is very powerful when used correctly. This practical session will show how to get the best from these powerful, built-in tools.
“There is a server monitoring in ColdFusion, and there has been for some time, but I'll explain in a minute what the best feature of that is, which is better than most others that's out there, the commercial tools. Yeah, absolutely if you're going to put new code out there of any note, you know you need to check what's going on, because again, it's like flogging a dead horse, it's not expensive to do so, apart from time.” – Mike Brunt
- Why monitor your CF server?
- 18% in the State of the CF survey don't monitor
- Why use the built in CF Server Monitor?
- What versions of CF is the server monitor in?
- The hidden features of CF stat
- Why you should be load testing your CF apps?
- And how to do it for free.
- Why are you proud to use CF?
- WWIT to make CF more alive this year?
- What are you looking forward to at Into The Box?
And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.
Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.
What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.
And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.
You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.
All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.
Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.
No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens Next
Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.
√ Easily create a consistent server architecture across development, testing, and production
√ A modern test environment to prevent bugs from spreading
√ Automated continuous integration tools that work well with CF
√ A portable development environment baked into your codebase… for free!
Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.
Mentioned in this episode
- Free server monitor tools
- Server monitor snapshot in one file of queries, JVM state when you reach a monitor limit
- Runs on Jetty, separate JVM container
- JVM monitoring tools
- JMeter load testing tool
- Blaze Meter
- Taffy API
Mike Brunt also known as CF Whisperer.
(* WWIT = What Would It Take)
Michaela Light: Welcome back to the show, I’m here with Mike Brunt, also known as CF Whisperer, and we’re going to be talking about his upcoming into the box session, Tuning and Troubleshooting Using Cold Fusion Native Tools. We’re going to be looking at, well first of all we’re going to look at why you should be monitoring your server, and I’ll explain why some people don’t even do that, and how and why you use the built-in tools in the CF server monitor, the hidden features of CF Stat, and why you should be low-testing all of your CF apps. Welcome, Mike.
Mike Brunt: Hey, good to see you again, good to be here.
Michaela Light: It’s good to be here, good to be alive on the CF Alive Podcast.
Mike Brunt: Right.
Michaela Light: Before we get into what you’re going to be talking about, the into the box conference on troubleshooting and tuning Cold Fusion using the native tools, let’s back up a bit. Because in the recent state of the CF Union survey, 18% of people didn’t monitor their server at all, and the people who take that survey tend to be the people active on Slack and in forums, and what have you, so you’d hope they’re the cream of the cream of Cold Fusion developers, which makes me wonder of the people who didn’t take the survey, probably even more don’t monitor their servers. Why should someone be monitoring their Cold Fusion server?
Mike Brunt: Well because first of all, the logging in Cold Fusion is great, and it’s the best I’ve ever come across in any application server environment. There’s a wealth of information in there, and it’s a great place to start monitoring your server, and I’ll sit back and say everybody should monitor, think of production. It was Nielsen I think that had a survey some years ago which said after eight seconds, anyone on the webpage would go elsewhere if they had an alternative. Eight seconds doesn’t sound like a long time, but you know I wouldn’t still be doing what I’m doing if there wasn’t a lot of issues going on with performance on web servers and application servers, and it’s not just Cold Fusion. I have other clients, I’ve worked on PXP, I’ve worked on .net, and they all have their issues.
Just reiterating something here, espn.net, the logging in those environments, unless you buy a pretty expensive third party tool, it’s just not where it’s at. Now, I can do my work, and I’m presenting on a tool set for Cold Fusion, I can do my work without any external tools, I can do it by just literally looking at the logs. I’ve blogged a lot about that to try and help all this, but at the very least, we should be looking at those logs at least once every week.
Michaela Light: Either directly at the logs, or using a server monitor to see what’s going on.