Beginner’s Guide to Troubleshooting Slow Pages in FusionReactor
By: David Levin, CEO and Big Kahuna of Angry Sam Productions, Inc.
It happens to just about every developer, client, or boss who calls out of the blue and complains that one of their essential web apps is running slowly. “Wonderful,” you sarcastically say to yourself as you can barely recall how their app even works since you haven’t looked at it in over six months! So how do you begin troubleshooting slow pages?
The good news is that there’s an easy way to diagnose, debug, and troubleshoot performance issues without having to sift through thousands of lines of embarrassing legacy code. In this blog post, I will describe how to install and use FusionReactor, a ColdFusion/Lucee (CFML) application performance monitoring tool, so you can save the day and look like a hero to your boss and/or client.
I am going to assume you are running your CFML development servers using CommandBox. If you are not, you really should be these days. Installing FusionReactor is as simple as typing these two commands into the CommandBox CLI:
fusionreactor register XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
You’ll want to replace XXXXX-XXXXX-XXXXX-XXXXX-XXXXX with your actual serial number. If you don’t have a serial number, you can pick one up with 14-day free trial
Setting Up the Bean Counter Application
The bean counter app is pretty simple. All it does is execute a query and display the total number of records found in the database. If you like, you can download the source code of the app on
Once you have the codebase downloaded, navigate to the project directory and spin up a new server in CommandBox with the following command:
You will need to create a new data source for this example. I created a new MSSQL database called “beancounter” on my development machine with a single table called “bean.” You can create any column(s) inside the table you wish. You will also need to add the DSN to Lucee‘s Server Admin. Hint, the default password for Lucee/ColdFusion servers created in CommandBox is “commandbox”
After the server starts, if you don’t automatically see the bean counter home page, you can manually bring it up by typing the following in CommandBox:
The application home page loaded pretty quickly, so I don’t think there’s a problem there. Try counting all of the beans by clicking the link on the page.
Houston, we have a problem. The bean-counting page loads painfully slow. Surely it can’t take this long to count 0 beans! The good news is that we successfully replicated the client’s problem.
Troubleshooting Slow Pages using FusionReactor
The first thing we should do is open FusionReactor to dig deeper into what’s going on behind the scenes of our slow-running page. In the CommandBox CLI type:
You should be taken directly to the FusionReactor login screen. The default password for CommandBox installations is “commandbox” If you’re using this in production, you should pick a strong password and safely store it in your password manager of choice. Once logged in, you will see the primary dashboard. You can confirm you are viewing the proper app by checking the name in the upper right-hand corner. It should match the name of your server in CommandBox.
When hunting for performance problems, the first place I start is the request history. Click on the Requests button on the left navigation menu and select “History” from the list of drop-down items.
We should then see the WebRequest Transaction History screen, which displays a chronological list of requests in descending order. Right off the bat, we can see we have a problem – FusionReactor has even highlighted the slow request for us in bold red text:
To dig deeper into the problem of troubleshooting slow pages, click the details button on the right-hand side of the screen next to the request we want to analyze. You will then be taken to the Details screen.
The Details screen can be a bit overwhelming at first, so let us focus on a few basics. In the upper left-hand corner of the Transaction Details section, we can see the request’s status, which indicates that the request finished successfully. We also can see some information about the script path and URL that was used in the request. In our case, the troublesome page was the aptly named /slow-page.cfm.
On the right-hand side of the same tab, we can see the total execution time of the request. In this case, it took about 13.5 seconds to finish. Ouch!
Another vital part of the transaction details is the JDBC section. It summarizes all database operations that occurred during the request. In our case, we can see that 1 query was executed, and it took over 5 seconds.
Another handy feature of analyzing a request is called the Profiler. Click on the “Profiler” tab to get a more detailed view of what occurred during the request. FusionReactor does a good job hiding a lot of the unimportant stuff and only shows us the methods which took the longest time. In addition, everything is color-coded to make identifying trouble spots much easier to identify.
As you can see from the tree above our query only took up about 12% of the request while 87% was spent sleeping!
One of the most common performance problems people encounter relates to SQL operations or database communication. In our example, we have a troublesome query, so let’s start there to see if we can identify the exact problem. First, click on the JDBC tab on the transaction details screen. Then, FusionReactor can show us the exact SQL statement(s) executed for simple debugging.
It looks like someone added an intentional delay to the query statement! Who would do that? Lucky for us, this is going to be an easy fix. However, you may need to troubleshoot your query a bit more in-depth in a real-world situation. More often than not, you can fix slow SQL by ensuring your database is optimized with proper indexes and through other best practices.
Fixing the slow pages in your Application
At this point, we learned that our page, /slow-page.cfm, has two significant problems:
- There’s a poorly written SQL statement that needs fixing
- There’s some sleep code in place which delays page execution.
Next, we open /slow-page.cfm in our IDE of choice. As you can see, whoever wrote this page likely had some serious psychological issues. So let’s get to work fixing the page:
After some clever optimization, we can clean up the page with the following changes:
Checking Our Work
Once we have saved the changes to the slow page, re-run the requests in your web browser before returning to FusionReactor. You should notice that the page executes noticeably faster.
Switch over to FusionReactor and click on the Request history again.
Bingo. The request only took 6ms to execute. You can now deploy your changes and look forward to accepting your hero medal from your client and/or boss.
A Happy Ending
FusionReactor is a powerful ally to have in your pocket whenever you develop or troubleshoot slow pages. It can help you identify bottlenecks in your software even before you deploy to production. If you’d like to learn more about FusionReactor, be sure to check out FusionReactor’s videos for a variety of tutorials and different ways to help your CFML development processes.
If you’re interested to learn more about me or my freelance web development or consulting services, please check out my website, or you can message me on Twitter.