FusionReactor is a necessary tool if you’re running a ColdFusion application of any appreciable size. Not helpful, not convenient. Necessary.
It provides insights and alerts that you’re not going to get anywhere else, and in many cases it’s the only tool that’s going to be able to help you track down obscure bugs, memory leaks, or other issues that make you want to pull your hair out. And on top of that, the team behind it is incredibly responsive and always pushing the product forward.
What do you dislike?
The price of the Ultimate Edition is the biggest pain point. Configuration and use within a containerized environment continues to improve, but still isn’t as strong/easy/helpful and the on-premise FR offering.
Recommendations to others considering the product:
If you’re considering FusionReactor, talk to the team there and evaluate the product (it’s free to trial). They can answer your questions and help you get started. There’s no-risk, and the benefits are obvious from the moment you start using it.
What problems are you solving with the product? What benefits have you realized?
The benefit is twofold. 1) FusionReactor provides alerting when there are issues with our applications. We set thresholds for memory usage, request quantity, or request length, and we get alerts when they’re exceeded. This is helpful in proactively addressing potential issues. 2) FusionReactor also provides detailed insight into what is going on within applications, which we’ll use when we need to track down the cause of a problem or an area that we’d like to optimize.
The most helpful feature of FusionReactor is the fact that you can introspect all the requests running in production. You can easily see how much time it takes to run a specific process, identify its pain points and optimise them. What is highly appreciated is also the profiling functionality! You can even profile your app and dig into very low level optimisations which otherwise would be not easily pinpointed!
What do you dislike?
What probably needs more rework is the documentation when you are exporting the java cache files from the FR JVM. I spent quite some time looking into what each value ment, which could have been better documented.
Recommendations to others considering the product:
Since there is a lack of actual debugging tools for ColdFusion, I consider FusionReactor to be the only tool that actually gives you an insight within your application!
What problems are you solving with the product? What benefits have you realized?
Real time monitoring of processes is a huge benefit. Optimising slow processes is a huge plus.
In my last article on FusionReactor, I talked about slow pages and how the tool helps you find them. In that article I specifically avoided talking about one of the biggest culprits of slow pages – database queries. My history with ColdFusion goes back to about version 2 and even back then database queries were the primary culprit in poorly performing applications.
There’s multiple reasons why database queries can be a choke point for your application:
A poor connection to the database.
A poorly configurated database.
A poorly configurated table.
A poorly written query.
And so forth.
In an ideal world, your organization has a DBA (database administrator) who tunes the database and tables and then crafts a beautiful SQL (or stored procedure) you can simply drop into your application. Unfortunately very few of us live in that ideal world. It’s also very easy to simply ignore the problem. SQL, like any language, let’s you get stuff done quickly and it can be easy to not consider the performance aspects of your query. Like any poorly written piece of code, a “slightly bad” query in a request can then be joined by another slightly bad one and slowly compound into a poorly performing page.
Being that database activity is such an important part of performance, it’s no surprise FusionReactor has specific reporting tools focused on just that area. In this post I’m going to share what that looks like and share some examples of the kind of reports you can find.
In my last post, I explained that JDBC stands for Java Database Connectivity. Any time you use a cfquery tag (or queryExecute function), you’re making use of JDBC to allow your ColdFusion templates to speak to a database. Within FusionReactor, you’ll want to start with the JDBC icon on the left:
Under here you’ve got a variety of options:
JDBC Activity – i.e. what’s going on right now.
JDBC History – historical activity.
JDBC Error History – past query errors.
Activity Graph and Time Graph – a “live” graphical report of JDBC activity.
Longest Transactions and Slowest Transaction – to be honest this was a bit confusing. Wouldn’t the longest transaction also be the slowest transaction. The “Longest” report will show the transactions that have taken the longest to execute, no matter how long. The “Slowest” report is a report of all transactions over a particular threshold. So it may be possible that you have nothing there as your queries are performant, but the “Longest” report will still rank them for you.
Trans. By Mem – reports on queries with high memory usage.
Stack Trace Filter – it’s possible that multiple different things are making use of your database. The stack trace filter lets you reduce the amount of “noise” you may get from other applications. By default there’s filters set up for .cfm, .cfc, and .jsp.
Databases – this gives a really cool report on how you’re using your databases. I’ll be sharing an example of this later.
Settings – this is where you can configure how FusionReactor logs and monitors your database transactions
Examining Database Requests
Let’s take a look at how FusionReactor reports your database requests. First we’ll open the “JDBC History” page. Remember that the first option shows a “live” version and unless your site is actively getting hits, you won’t see anything.
As with the previous examples I’ve shown from FusionReactor, take note of the controls on the top right allow for filtering, reloading, and so forth. What isn’t obvious from the screen shot is that the “All SubFlavors” button actually lets you filter by the type of query, select, insert, and so forth. That’s pretty neat.
The main table of data reports on the app that was being used (I’m just working in my default Lucee home directory) and the SQL that was used. You can see the file name as well as timing information. Note the Time column which shows you how long the particular query took.
Notice how the SQL is reported as well. One of the features of FusionReactor is to automatically replace queryparam values with their ‘real’ values when reporting on the query. You can enable or disable this feature under the “JDBC/Settings” page. While this is a cool feature, it means it’s difficult to see where you’ve forgotten to use queryparams. I’ve reported to the FusionReactor folks that it would be nice if it was obvious when such a replacement has happened, maybe by using bold tags or some such. That way if you a query is not using queryparams it will be easier to find and correct.
The detail view is very deep. Here’s the main tab of information:
There is almost an overwhelming amount of information here, but I’d probably focus mostly on the execution time values under JDBC and the memory section. Here’s the JDBC tab:
As before, there’s a lot of information, but I’d focus in on the row count. If you’ve ever seen someone select everything from a table and then use ColdFusion conditionals to restrict what is shown, then you know why this is a problem. The query is returning a mind boggling twenty-seven thousand rows. There’s no way that was intentional. (Ok, for my test it was, but you get my point.)
The final tab, Relations, gives you a good look at the query within the page it was working. For example, this page had multiple queries and you can see how they impacted to the overall total page performance.
Finding Query Errors
Let’s now take a look at how FusionReactor reports errors. To test, I ran two requests with simple SQL errors, one trying to get a field that didn’t exist and one against a table that didn’t exist. Here’s how the main error history page shows the results.
For the most part this is fairly similar to the history report, except now you can get a short report of the error. As a test, I shut down my MySQL server and ran my request again. As expected, I got an error. However, that error does not show up in this report. It does show up under “Request/Error History” though. My guess is that since Lucee couldn’t ever speak to MySQL, a JDBC transaction was not made. That makes sense to me, but just keep in mind that you may want to check both error reports when hunting down issues.
The detail view is the same as before but with a new tab called “Error Details”:
As always, I find the stack trace a bit hard to parse, but the error details on top seem nice and clear to me. Notice the debug button on the right. This allows you to add a breakpoint for future errors like this. I’m going to talk about FusionReactor’s debugging features later.
FusionReactor offers two reports of JDBC activities. The first is just raw activity (Activity Graph) while the second (Time Graph) reports on how long queries are taken. Both default to a “live” view but also let you look at specific time ranges. Here’s an example of both, but note the graphs are a bit boring for me as this is just my local laptop.
Finding Those Bad Queries
As I explained above, FusionReactor provides two reports to help you find slow queries. “Longest Transactions” will simply list out all your recorded transactions sorted by time. “Slowest Transactions” focuses on queries that are slower than a defined threshold. You can set that threshold in the settings panel, under “History”. The default value is 3 seconds. There’s quite a few interesting things you can tweak in the settings panel so I recommend taking a look at it. For my laptop, with again a simple test and not “real” data, here’s the “Longest Transactions” view:
Your Database Use
The final thing I want to show is probably the coolest. The “Databases” report gives you a report on how you are using each of the datasources on your server. It breaks it down by type of operations as well as table usage. It also reports on the queries sent to the datasource.
This is just freaking cool as heck to me. While I think most of us will deal with one database per server, larger more complex applications could be dealing with numerous databases. A report like this could help you figure out if one, or more, are perhaps being used rarely enough to be decommissioned or transitioned to one main database. The table report could be really useful too. I’ve dealt with projects hitting a database with a huge amount of tables. This can give you an idea of what’s actually being used.
As I said in the beginning, database issues tend to be the number one culprit when it comes to poorly performing ColdFusion sites. I think the JDBC set of features in FusionReactor will probably be your top tool for helping improve your applications. I know this is where I’d start looking!
Thanks to our special guest author Raymond Camdem for writing this article for us.
Have you wished you could change the name given to your monitored instance in FusionReactor (the name that appears in the UI and various reports/emails)? Did you know you could change it easily, on the fly, from within the instance and without need of restarting your instance?
Finding (and Fixing) Your Slow ColdFusion Pages with FusionReactor
In my last article I described how I wanted to help introduce FusionReactor to ColdFusion developers with a special focus on helping solve practical problems and navigating terminology that may not be terribly familiar with if you haven’t used Java before. In that first article I focused on using the FusionReactor portal to find and diagnose pages that were throwing errors. In this follow up I’m going to highlight another great use of FusionReactor – finding slow pages.
Slow pages can be difficult to find. A page that runs fast on your local server could run much slower in production. A page with a complex set of inputs, like an advanced search field with numerous filters, can only run slow when a particular unique set of choices are made. Sometimes your code can be absolutely perfect, but an external factor is the culprit. Perhaps you’re integrating with a database that you have no control over, or maybe you’re using a third party API that has performance issues of its own.
In this article I’m going to highlight multiple examples of slow pages and how FusionReactor can help you find, and hopefully fix, each of them! Ready?
Finding Your Slow Requests
Before we begin writing some horribly slow code (I’m a pro at this!), let’s look at where FusionReactor displays these requests. In your left hand menu, under Requests, select Slow Requests:
You’ll notice the display is split between currently running slow requests and requests that have already finished but were considered slow. Which begs the question – what’s “slow”?
Under Requests, go to Settings, and then select WebRequest History. Here you will find multiple settings you can configure including what the threshold is for something being considered slow. In my FusionReactor 8 instance this was set to 8 seconds.
And just to be re-iterate, this is important even if your ColdFusion page isn’t returning markup. If you are using ColdFusion to power a client-side application with JSON data, then you still need to ensure you’re returning a speedy response.
So yes, this is very, very important stuff. I’d go ahead and change that number from 8 down to 1 or 2. See what works best for you.
Another view of your slow requests is the Longest Requests view, also found under the Requests menu:
This is a sorted view of requests with the slowest being displayed first. This is not filtered by the Slow Request threshold but covers everything. Also note it includes non-ColdFusion files as well!
Bring the Slow
Let’s start off by demonstrating two slow pages. One is always going to be slow and one uses an external resource that will also always slow. Here’s the first one:
Go to sleep...<br/>
It simply uses the sleep function to pause the execution for 30 seconds. If you’ve never seen cfflush before, it tells the ColdFusion server to send out existing output to the browser. As a user, you would see the initial HTML, the browser continue to load, and then the rest of the results.
This will definitely cause a slow request to be logged. Unfortunately, unlike the error conditions we saw in the previous article, it’s a bit more difficult to diagnose. Let’s see why. First, here’s the details page for this particular request.
There’s a few things to note here. First, the slow time is nice, bold, and red. You can’t miss that and that’s a good thing. Now make note of JDBC. Don’t know what that means? JDBC is the acronym for Java Database Connectivity. Basically this is how ColdFusion speaks to databases. I started ColdFusion development way back in 96 or so, before ColdFusion ran on Java, but even back then the biggest culprit for slow requests was issues at the database layer. We aren’t doing any database requests on this page but nine times out of ten you want to turn your focus here. Every single one of those metrics is crucial and can be a flag for an underlying issue.
As a real example of this, I was working with a client and discovered they had about 1000+ database queries being run in a request. How did this happen? They had queries in an Application.cfm file, queries in a header file, queries in a file loaded by a header file, and so on and so on. 90% of these queries were the exact same query run multiple times. They weren’t stupid – they just didn’t realize everything going on in one particular request. This can happen as a web application grows larger and more complex, and is yet another reason to consider a tool like FusionReactor!
Alright, but this template isn’t slow because of a query. What do you do next? Click on the Profiler tab next. (And note, back in the main list of slow requests, every slow request has a direct link to this particular view.)
So in this case, you can’t really get to a particular line of your template or ColdFusion method. But even if you’ve never used Java before, seeing 100% correlated to java.lang.Thread.sleep should give you a clue as to which particular tag was the issue.
Let’s consider another example, this time the ColdFusion template is using a third party API built on a serverless platform:
In this case, the serverless function I’m hitting is using setTimeout to delay the response for 3001 milliseconds. This page is going to be slow, but it’s something out of ColdFusion’s hands. (But to be clear, this is still something you could address. Can you cache the result? Can you fire it via a scheduled task and store the result locally? You’ve got options!) So how is this reported in the profile?
In this example, you can see two things that stand out – first Http.java and then Dump.cfc. The later clearly refers to the cfdump tag which typically wouldn’t be run in production. But Http.java should definitely be enough of a clue to tell you where the issue is. Of course, you may run into an issue if you have multiple HTTP calls in your ColdFusion page. In that case you’ll need to do further testing to see if you can determine the culprit. The important thing to note though is how FusionReactor got you nearly 100% of the way there!
In this article I simply introduced the Slow Request views in FusionReactor and used it to find a few problem scripts that should be fixed. In my next article I’m going to turn my attention to database specific issues and show you how FusionReactor helps there. As always, leave me a comment below if you have any questions!