While in the process of stress testing our application under an updated software stack, I stumbled across the fact that FusionReactor has been dramatically impacting our performance under load. While I knew FR has some impact in performance, their claims are it’s negligible (and that was certainly my experience when we started using the product).
However, I was doing some stress testing of our application and noticed that as soon as I installed FR our performance dropped 60%+. Here are the results of the stress tests:
| Before FR installed | 33,395 requests |
| After FR installed | 12,357 requests |
It turns out, by default, FusionReactor enables a feature to trace exception stacks by default when using with Lucee. It’s disabled when installed in Adobe ColdFusion because of this performance hit.
Per the documentation:
In certain scenarios, such as when using specific frameworks, libraries, or code that generates frequent exceptions, caution is advised. This is because enabling this setting may lead to a performance impact, resulting in FusionReactor slowing down your application. To mitigate this issue, it is necessary to disable exception support using the following argument:
-Dfr.jvmti.enable.exceptions=false
After making this change and restarting our Tomcat configuration, that brought the performance back up to par with the minimal impact I expected FR to have:
| Before FR installed | 33,395 requests |
| After FR installed | 12,357 requests |
| FR installed, exception tracing off | 31,443 requests |
I went back to our current stack and see that FR was having the same negative performance impact on Lucee 5 as well.
The issue is that this feature ends up tracing internal exceptions in libraries that are catching exceptions and handling them gracefully, so even if your application code is not generating exceptions, this can end up really impacting performance.
So what do you lose by disabling this feature?
I asked that same question from Integral and here is the response I got:
Exception tracking causes dramatic performance impact because it activates a special JVM mode that monitors all exceptions in the JVM, even caught ones that are handled internally by libraries.[1] This mode tracks exceptions comprehensively across your entire application stack, not just uncaught exceptions.[2]
What you lose by disabling exception tracking:
- Event Snapshots for exceptions - These capture application state when exceptions occur, providing detailed debugging information[3]
- Exception breakpoint support in the Production Debugger - You can’t set breakpoints that trigger when specific exceptions are thrown
- Exception log capture - Stack traces of errors within tracked requests won’t be automatically captured
Why you haven’t seen Event Snapshots:
Event Snapshots require both the JVM argument enabled AND manual activation in the UI under Debug > Event Snapshot tab.[4] They don’t appear automatically even when exception support is enabled.
In our case, this isn’t something we were enabling in the Event Snapshot tab and using the debugger is not something we do in production, so disabling this feature is a no brainer for us. If we run into a weird production issue where we need the feature, we will just temporarily enable it and then turn it off again.
Summary
If you are using FusionReactor (and you haven’t done so recently), I would recommend doing some load/stress testing on your application to see if this feature might be negatively impacting performance for you. I was definitely surprised at the results!
I still 
FusionReactor. It’s an amazing tool, but this particular nuance had previously escaped me.