One of the most important resources for a Web developer are their tools. If I asked you to name a few of your most used tools, you'd more than likely talk about your programming tools - things such as your IDE of choice, unit testing and debugging tools, SQL tools, FTP software, your browser, and source control software.
In fact, I asked the developers on my team at Dealerskins this very question and most named all or some of the above. Other tools incredibly important to a Web Developer are load testing and performance monitoring tools. These types of tools are most often used by systems administrators or QA engineers, but our senior development staff are just as likely to wire up DAO's as they are to check our overall ColdFusion platform performance. Which brings me to the point of this post.
We've been using FusionReactor Enterprise on all our ColdFusion servers for three years and I can't imagine not having it in our arsenal. A few months ago the folks at Integral, makers of FusionReactor and FusionDebug, interviewed me for a case study on our use of FusionReactor. The case study was published this week on their customer page (or you can download the PDF from this page).
While the case study is a great overview of our use of FusionReactor and its impact to our business, I want to elaborate on three benefits mentioned in the study.
Support staff are immediately alerted to any potential server issues via the Enterprise Dashboard - enabling fixes to be quickly put in place and keeping customer service impact down to a minimum.
FusionReactor's Enterprise Dashboard is a fantastic tool for getting clear visibility into the performance and health of a Java/ColdFusion platform. Our systems department has a flat panel display mounted in their office that does nothing but display real-time performance metrics. Most of the metrics are from the Enterprise Dashboard while other metrics monitor critical infrastructure not related to our ColdFusion platform. If a problem occurs on a ColdFusion server, an e-mail server, or a database server we know almost instantly. We're able to see which part of our platform is affected and how severe the problem might be.
Sometimes the dashboard provides actionable information and other times it simply tells us where we need to go next. For example, if one ColdFusion server is showing performance problems we can drill into that server and determine if the problems are related to threading issues, memory issues, or even an issue with connections to our database platform. The blue/yellow/red colors make "at a glance" decision making possible.
Running FusionReactor on all production servers, enables Dealerskins to gather performance, benchmarking and tuning data, which is used by their development teams to improve the overall quality of applications, by reducing memory consumption and increasing request throughput.
In addition to real-time performance monitoring we use FusionReactor to gather data to help us make critical long-term infrastructure/architecture decisions. Simply put, we don't do anything until we have data to back up our actions. Some might argue this makes us slow to make decisions. On the surface that might hold some truth but it also means we rarely make bad decisions. I personally believe there's a blurred line between being decisive and being hasty. There's also risk to decision-making, and you can't wait until you have 100% of the data but the key is getting the right amount of data to make a great decision.
We constantly look at our recent performance data, trending whether we're going up or down in page response times, query performance, JVM memory management, overall page hits and more. Peering into this data helps us understand our platform better and know where we CAN optimize and where we NEED to optimize. One example of this was with a recent change in the number of queries we were generating from ColdFusion to our database platform. Since we monitor this number on a regular basis we were able to see a dramatic increase in queries after a code rollout when we expected to see a decrease. Knowing what our expected success was - less queries - and visualizing the actual result, we were able to dig further into FusionReactor and our database servers to discover the problem. It turned out to be errant ColdFusion code clearing some query caches when it shouldn't have. We made a ColdFusion code change, deployed the change to our staging platform and did some testing. We verified the fix and deployed it to production. It was pretty cool to see the number of queries immediately drop in our database monitoring tools.
Benchmarking and testing data provided by Fusion Reactor was instrumental to supporting us in our recent migration to ColdFusion 8.
During the summer of 2008 we moved our operations to a brand new, state-of-the-art, in-house datacenter. Part of the datacenter migration project was getting all our ColdFusion servers running on the same version. We had been running ColdFusion 8 Enterprise on our local development machines and our staging environment, but our production servers were a hodgepodge of ColdFusion 7 and 8. We performed weeks worth of load testing using Open Demand's Open Load product while monitoring everything with FusionReactor. During the actual live traffic migration - a process that to this day scares the crap out of me - we used FusionReactor to watch traffic filter off of one datacenter in the southeast to our new datacenter. I wouldn't have had near as much confidence in our new system if we hadn't performed so much testing with Open Load and FusionReactor. And the overnight migration would've been about 1,000 times scarier!
If it's not crystal clear at this point we really depend on FusionReactor. If you've been reading through this post wishing you had the same level of clarity and visibility into your ColdFusion server(s) you owe it to yourself to check out FusionReactor. And if you have questions about how it works or what it can and cannot do feel free to e-mail me or comment right here.