Review Of FusionReactor Part II

Nov 06, 2016

This has taken a while to complete due to work pressures and learning a bit more about FusionReactor by using it with several clients. Before starting fully I wanted to share this item "According to a new study 43 percent of app developers spend between 10 and 25 percent of their time debugging application errors discovered in production, rather than developing new features." .  The FusionReactor team just released something which will help greatly in this regard, production debugging; more on that soon.

FusionReactor was created initially as an APM tool for Adobe ColdFusion, as was SeeFusion also.  The fact that ColdFusion uses a JVM scripting language called CFML means that FusionReactor can easily be used with Java based languages and Servlet Containers such as Glass Fish, Tomcat, Jetty etc. Over the years I have used many different APM centric tools and none have been totally sufficient to solve problems wholly in their own right, in fact in many cases, logs have been more useful, especially metrics and JVM garbage collection logging. However FusionReactor has helped me more than most others because exactly of logging, no product I have ever used has such detailed logging as FusionReactor and I will give a few tips in this article as to why and where in the logs.

We finished the last piece with this screen which shows the JVM instances which FusionReactor found as a result of scanning the operating system, in this case a Windows 
based system.

Let's dig into using FusionReactor in a real-time lab load-test using JMeter 3.0 against a deliberately "crippled" ColdFusion 2016 application.


On this screen we can view real-time behavior and history too, the main screen here has three main sections, from left to right; Web Requests, JDBC metrics and JVM heap and system CPU metrics.  There are other views via a drop-down which are essentially sub-sets of overall metrics.


Here there are various different views of request information, this shows recent request history and once again there is a drop-down for other views of request activity, once again in real-time and history also.  Note the 500 errors here, we will return to those in the debug section below.


The screen we are showing relates to user sessions and the application we are testing against does not have a log-in capability, however we can see some session information in this screen shot.


Here there are various different views of transactions; here we are showing  web requests history in real-time, there are historical views also available.



A step-through debugger is not something we typically see in a production environment.  However as adequate testing before code deployment is getting more difficult because there are far more dependencies in modern day applications, debugging of this kind, in production, could help us find root causes of issues in a real world scenario. 

Here we see the Longest Transaction view in FusionReactor and we can see there are two 500 errors, if we click the "Profiler" link under the URL FusionReactor opens the Profile view of the request, as shown below.

At the bottom of the page are all the requests and method calls.  Clicking on the one we want to select to set a breakpoint opens the dialog box below.

Once we confirm the setting it is all ready to go and we get the screen below.

Debugging is ready to go and note the pause time is set to 60 seconds.

Here we see three threads paused which is the number we chose when setting up debugging.

Looking at the results in JMeter we can clearly see the thread was paused for just over 60 seconds which is the value we chose in setting up debugging.

Overall, I view this as a very powerful feature worthy of a blog entry by itself.  In the meantime there is a very good video here which goes into the debugger in far more detail than I have done in this blog piece. 


Profiling Java on production systems can be both hard to set up, quickly; and can be very heavy, imposing their own overhead.  The Profiler in FusionReactor is neither and yields great information on all aspects of performance issues, including offending method calls, JDBC and network level issues via TTFB information.  This is a very powerful feature indeed.


Here we can see details for system network, disk I/O, RAM and CPU.  Certainly very important information in any troubleshooting requirement.  Often application code gets the blame for all ills and I have often found other reasons in my years of troubleshooting.


The main dependency that all web applications have is the database, it is vital to be able to monitor both long running SQL and any connectivity challenges that may come along and FusionReactor enables this by default.  This is the history from the JDBC section in FusionReactor, this information is also available in other sections as noted above.


Here we are offered many levels of monitoring and notification on all aspects of our applications.  In my experience I never let a utility kill a request but set it to email any threshold issues that are reached.


This allows compression of request responses and I have never used it so do not have any feedback.


This is something else which I have not used yet it does look useful in setting up responses quickly without having to dive deeply into code to do so, 404 responses for instance.


This is where the logging characteristics of FusionReactor are set, as I intimated at the beginning of this article FusionReactor has plethora of logging in place and there are a good number of ways to configure those.  By default FusionReactor creates 23 logs which it writes to some of (it depends on settings) and these are archived hourly, then daily.  My tip here is if you are troubleshooting performance issues, the resource.log is particularly good showing system and Servlet Container data in 5 second increments.  Select a particular hour of problems and you can really dig into those.  I created spreadsheets to analyze these logs in my work.


This set of options relates to an add-on product from Intergral, the supplier of FusionReactor, called FusionAnalytics, I did not use this in this review.

This completes the in-depth FusionReactor review and I hope this will help in your ongoing performance and JVM tuning and troubleshooting efforts.










About Mike Brunt

Mike has been working since 2001 on all things Java server-side. This includes, troubleshooting, tuning and infrastructure design, engineering and migration. More ...


Monthly Archives

Favorite Links

Tag Cloud

jvm java java containers capacity planning load testing internet of things blockchain android