You may have noticed in the FusionReactor UI that requests which are “slow” have their duration show up in red in the FusionReactor UI. The default is 8 seconds, but what if you would prefer to lower that duration to something like 3 seconds instead? That could be important, and it’s easy though many might never realize it was even an option.

In this post, I will show you how to change that easily, and how to see the impact of that setting on other pages of the UI. I’ll also address changing the JDBC or “transaction” threshold also. (These settings apply only to the traditional FusionReactor “on-premise” UI as opposed to the newer FR Cloud UI.)

By way of introduction, I love FusionReactor and use it every day, and I’ve been showing people how to make the best use of it for nearly 15 years, including over a dozen past hour-long webinars, as well as in my own blog and other community resources. I want to start sharing tips here on the FusionReactor blog, both to help an even wider audience and to show my support for the fine folks who make FusionReactor, who are all excellent people. (If I can continue offering these posts, we may label them as a series.)

Where to see/change the “Slow Request Threshold”

This setting, which defaults to 8 seconds, is set in the FusionReactor (on-premise) UI in the Requests button on the left, and its Settings option:

Then its “WebRequest History” option and finally its “Slow Request Threshold” setting:

Where to see the impact of the Slow Request Threshold

Again there are primarily the two ways I mentioned above where you would see the impact of the “Slow Request Threshold”.

First, notice that in any list of requests (including most pages under the Requests button on the left, including Activity, History, Error History, Slow Requests, Longest Requests, and so on), if the duration of a request exceeds the threshold, then the duration time (in ms) is shown in red.

Here’s an example showing that on the Requests>History page (in the on-premise UI), which by default shows the 100 most recent requests, regardless of duration. Notice how some (but not all) requests show their duration in red (with the less bolded red indicating just barely over the threshold):

The second place I mentioned is the Requests>Slow Requests page, which focuses solely on “slow” requests meeting this threshold: specifically, it shows the most recent 100 (also configurable) requests which were “slow”. Here’s an example of that:

Other pages impacted by these settings

There are still other places that the “Slow Request Threshold” has an impact. In the Metrics>Web Metrics page, the text below the graphs has some counters about “slow” requests, and that would be impacted by this setting.

There is no relationship between this setting and things like the FusionReactor (FR) logs or Crash Protection alert emails.

Again, the setting seems to have no impact on the FR Cloud UI, from my assessment of things. (I realize some readers will not be aware of what is the FR Cloud offering, or how to find it, use it, enable it, and more. That’s good fodder for future posts.)

Some related topics

Before moving on, there are a few related topics that we can consider briefly.

Consider also the “Slow Transaction Threshold”

First, while the focus of this post has been the “Slow Request Threshold” and the tracking of slow requests, some readers may notice that the various pages showing JDBC requests and transactions (under the JDBC and Transaction buttons on the left, respectively, of the FR on-prem UI) also can show duration values in red–but those trigger at 3 seconds (by default) instead of 8.

How could you change that default of 3 seconds (if perhaps you wanted to regard queries taking even 1 second as being slow)?

It’s a little confusing: you might look for that in the JDBC>Settings or Transactions>Settings pages, but instead, it’s in that same Requests>Settings that I first mentioned. Then it’s on the “Transaction History” page (right below the aforementioned “WebRequest History” page). See the “Slow Transaction Threshold” (and related settings).

Controlling how MANY requests appear in the Slow Requests, JDBC,  and Transaction pages

While on the topic of the “slow” pages for Requests, JDBC,  and Transactions, you may wonder how to control how MANY items appear on those pages. Again, the “Threshold” settings discussed above govern what duration leads things to appear on them.

If you look at the first screenshot above (WebRequest History), note that there is a also “Slow Request History Size”. That controls HOW MANY requests appear on the “Slow Requests” page. And In the Transaction History page, I just mentioned, there is a “Slow Transaction History Size”, which governs how many JDBC or Transactions appear on their respective “Slow” pages. (This also governs how many appear within the JDBC section within a request’s details.)

Be careful when raising either of these sizes: FusionReactor is conservative in its setting of such “sizes,” since the larger you make them, the larger their respective lists will be and the longer it will take to render the page–and the more heap will be used within your monitored instance, though the usage is tiny with the default settings.

My webinar on tweaking other configurable FR settings

If you liked learning of these settings, you may like still other ones that I share in a 2017 webinar I did on “Configuring FusionReactor for Action“. I was surprised to see that this topic was NOT among the many, many configurable settings I covered in that hour–but that just shows how many others there are! 🙂

Because most of my FusionReactor webinars are from a few years ago, they are no longer offered on the FR website (on their video tutorials page). And while there have been new FR versions since then, most of the things I discuss are still relevant and found in the same places now.

But do check out that video tutorials page also, They are not only short but more polished (with scripted narration, with professional voiceover), and they often focus on still-newer features.

Conclusion

That’s quite a bit to consider for such a simple setting. And this is often the case: FusionReactor surfaces so much value that folks may be satisfied for years with what it offers and may never even dream there’s a way to tweak things to make them still more valuable. And I hope to tease out of those older webinars of mine some of the many hidden gems I shared, to offer in new posts to come and perhaps new videos.

Again, I love helping people use FR. In fact, I do it daily in my consulting. If I can ever help you solve a knotty problem (whether it may involve using FR or not), you can find more and reach out at https://www.carehart.org/.