FusionReactor Blog - News and expert analysis for Java APM users.

Win a FREE Ticket for Velocity Conference Amsterdam , 2016

fusionreactor-win-velocity-tickets

We are sponsoring Velocity Conference,  Amsterdam. You can visit us at booth #416, we will be showing off the latest version of FusionReactor and FusionReactor CLOUD. To celebrate this we are giving away a free ticket for Velocity Conference, Amsterdam.

The Prize is for one Bronze 2-Day Pass which Includes:
– All sessions (Mon & Tue)
– All keynote and plenary presentations
– Sponsor Pavilion and all events held there
– All on-site networking events
– Lunch (Mon & Tue)

There are Two ways to enter the draw:
1) ON TWITTER : Retweet this tweet and follow us it is that simple! If you are already following us then just retweet this.

OR (You can do both to double your chances of winning).

2) ON FACEBOOK : Just Like us on Facebook –  and post us a Personal Message – “I want to go to Velocity Amsterdam”
We will be announcing the winner on,  Friday 21st October, this will give the winner enough time to organise flights and accommodation.

If you do not win, please do not worry you can still save 25% on the entry price by using our Discount Code: FusionReactor25

 

Java Buffer Pool Memory Space

Understanding the Java Buffer Pool Memory Space

The Java buffer pool space is located outside of the garbage collector-managed memory. It’s a way to allocate native off-heap memory.  What’s the benefit of using a Java buffer pool? To answer this question, let’s firstly learn what byte buffers are.

Byte Buffer

Non-Direct Buffer

java.nio package comes with the Bytebuffer class. It allows us to allocate both direct and non-direct byte buffers. Their is nothing special about non-direct byte buffers – they are an implementation of HeapByteBuffer created by ByteBuffer.allocate() and ByteBuffer.wrap() factory methods. As the name of the class suggests, these are on-heap byte buffers. Wouldn’t it be easier to allocate all the buffers on the Java heap space then?   Why would anyone need to allocate something in a native memory? To answer this question, we need to understand how operating systems perform I/O operations.   Any read or write instructions are executed on memory areas which are contiguous sequence of bytes. So does byte[] occupy a contiguous space on the heap? While technically it makes sense, the JVM specification does not have such guarantees. What’s more interesting, the specification doesn’t even guarantee that heap space will be contiguous itself! Although it seems to be rather unlikely that JVM will place a one-dimensional array of primitives in different places in memory, byte array from Java heap space cannot be used in native I/O operations directly. It has to be copied to a native memory before every I/O, which of course, leads to obvious inefficiencies. For this reason, a direct buffer was introduced.

Direct Buffer

A direct buffer is a chunk of native memory shared with Java from which you can perform a direct read.

An instance of DirectByteBuffer can be created using the ByteBuffer.allocateDirect() factory method. Byte buffers are the most efficient way to perform I/O operations and thus, they are used in many libraries and frameworks – for example in Netty.

Memory Mapped Buffer

A direct byte buffer may also be created by mapping a region of a file directly into memory. In other words, we can load a region of a file to a particular native memory region that can be accessed later.  As you can imagine, it can give a significant performance boost if we have the requirement to read the content of a file multiple times. Thanks to memory mapped files, subsequent reads will use the content of the file from the memory, instead of loading the data from the disc every time it’s needed. MappedByteBuffer can be created via the FileChannel.map() method.

An additional advantage of memory mapped files, is that the OS can flush the buffer directly to the disk when the system is shutting down. Moreover, the OS can lock a mapped portion of the file from other processes on the machine.

Allocation is Expensive

One of the problems with direct buffers is that it’s expensive to allocate them. Regardless of the size of the buffer, calling Buffer.allocateDirect() is a relatively slow operation. It is therefore more efficient to either use direct buffers for large and long-lived buffers or create one large buffer, slice off portions on demand, and return them to be re-used when they are no longer needed.   A potential problem with slicing may occur when slices are not always the same size. The initial large byte buffer can become fragmented when allocating and freeing objects of different size.  Unlike Java heap, direct byte buffer cannot be compacted, because it’s not a target for the garbage collector.

Monitoring the Usage of a Java Buffer Pool

If you’re interested in the amount of direct or mapped byte buffers used by your application, then you can easily monitor them using FusionReactor.   FusionReactor provides a break-down of all the different memory spaces.   Simply navigate to Resources and then Direct – Buffer Pools.

Java buffer pool, garbage collector-managed memory

By default, the Direct Buffer Pool graph is displayed. You can switch to the Mapped Buffer Pool by clicking on a drop-down in the top right corner. Java will grow those pools as required so the fact that Direct Memory Used covers Direct Capacity on the graph above, means that all buffer memory allocated so far is in use.

Please note – you can limit the amount of direct byte buffer space that an application can allocate, by using -XX:MaxDirectMemorySize=N flag.   Although this is possible, you would need a very good reason to do so.

Win a Ticket for Adobe ColdFusion Summit – Las Vegas, 2016

Win a Ticket for Adobe ColdFusion Summit – Las Vegas, 2016

cfsumit-web

 

The FusionTeam will once again be sponsors of this great event – make sure you join us and the Adobe ColdFusion Team! We will be showing off the latest version of FusionReactor and FusionCLOUD.

To celebrate this we are giving away a free ticket for the Adobe ColdFusion Summit.

The Prize is for one ColdFusion Summit registration which Includes:
– Admission to all keynote and breakout sessions
– Sponsor Pavilion.
– Attendee appreciation event
– Conference meals.

There are two ways to enter the draw:
1) ON TWITTER : Simply follow us and send us a Direct message saying ‘I want to go to CFsummit’

OR (You can do both to double your chances of winning).

2) ON FACEBOOK: Just Like us on Facebook – and post us a Personal Message – ‘I want to go to CFsummit’

We will be announcing the winner on, Friday 23rd September, this will give the winner enough time to organise flights and accommodation.

If you do not win, please do not worry you can still get a ticket for $199 on the entry price by using our Discount Code: CF199Offer

FusionReactor ColdFusion line performance

Introduction


This technote is going to guide you through the use and configuration of the FusionReactor ColdFusion line performance plugin. The FusionReactor ColdFusion Plugin is able to profile the execution of ColdFusion CFML code at line level. The data gathered can be used to identify performance issues deep inside ColdFusion pages and components that can be an invaluable tool for finding problems within your applications. Additionally, the plugin also gathers information about the CFML code coverage which can be valuable when testing applications.

If you are using Lucee or Railo application server and FusionReactor 6.2.0 or above, then you should be able to use the FusionReactor Lucee Plugin or FusionReactor Railo Plugin. More information about the plugins, check out the link below.

Getting Started


If you are using FusionReactor 6.0.4 or above and a ColdFusion 8 or above server, you will be able to use the FusionReactor ColdFusion Plugin.

Please be aware that this feature uses line number information generated by the ColdFusion application server that is known to be inaccurate in some cases and beyond our control. For this reason we cannot guarantee 100% accuracy of the information. Also note that the performance of the ColdFusion application server may be HEAVILY impacted while tracking line performance profile data.

In order to view any of the profiled data, you will require the “CF Line Performance Explorer” application. This can be downloaded from the link below.

When the tool has been downloaded, you will need to unzip the folder and copy the contents into your ColdFusion /wwwroot directory. Going to the following address, http://localhost:8500/cfperformanceexplorer-master/ you will see the following when you attempt to view a files metric data.

In order to enable the line tracking for your CFML files, please follow the steps outlined below;

  1. Access your FusionReactor Instance.
  2. Navigate to FusionReactor > Plugins > Active Plugins.
  3. Locate the FusionReactor ColdFusion Plugin and then press the Configuration button.
  4. Change the value of the “Track CFML Line Execution Times” field to “Enabled” and Save the changes.

This configuration is going to take immediate effect and any CFML code that is run and is going to be profiled. In order to see the results, please return to the CF Line Performance Explorer application to view the profile data for any classes that have been run since enabling of the plugin. See screenshot below.

Please note that though the data gained from the profiled classes may be invaluable the profiler can have a performance impact on your server. It is recommended to only use the profiler when required and to take precautions when using it in a production environment.

More Information


For more information you can view the following documentation.

Issue Details

Type: Technote
Issue Number: FRS-401
Components: Plugins + OSGi
Environment:
Resolution: Fixed
Added: 19/08/2016 10:30:37
Affects Version:
Fixed Version: 6.2.2
Server:
Platform:
Related Issues: None

FusionReactor Lucee and Railo line performance

Introduction


This technote is going to introduce the Lucee and Railo line performance plugins. The FusionReactor plugins allow you to profile the execution of ColdFusion CFML code at line level. This data can then be used to identify performance issues deep inside your ColdFusion pages and components and can be an invaluable tool for finding problems within your applications. This feature also gathers information about the CFML code coverage which can be very valuable when testing applications.

If you are using a ColdFusion server, FusionReactor 6.04 or above supports the FusionReactor ColdFusion Plugin. More information about the FusionReactor ColdFusion line performance, check out the link below.

Getting Started


If you are using FusionReactor 6.2.0 or above and a Lucee 4.5 server, you will be able to use the FusionReactor Lucee Plugin. However, if you are on Railo server then you will be able to use the FusionReactor Railo Plugin.

Currently Lucee 5 is not supported.

In order to view any of the profiled data, you will require the “CF Line Performance Explorer” application. This can be downloaded from the link below.

When the tool has been downloaded, you will need to unzip the folder and copy the contents into your Lucee or Railo /webapps/ROOT directory. Going to the following address, http://localhost:8888/cfperformanceexplorer-master/ you will see the following when you attempt to view a files metric data.

To enable the line tracking for your CFML files you can follow the steps outlined below;

  1. Access your FusionReactor Instance .
  2. Navigate to FusionReactor > Plugins > Active Plugins
  3. Locate the FusionReactor Lucce Plugin or the FusionReactor Railo Plugin and then press the Configuration button.
  4. Change the value of the “Track CFML Line Execution Times” field to “Enabled” and Save the changes.

This will take immediate effect and any CFML code that is run is going to be profiled. You can now return to the CF Line Performance Explorer application to view the profile data for any classes that have been run since enabling of the plugin. See screen below

Though the data gained from the profiled classes may be invaluable the profiler can have a performance impact on your server. It is recommended to only use the profiler when required and to take precautions when using it in a production environment.

More Information


For more information you can view the following documentation.

Issue Details

Type: Technote
Issue Number: FRS-400
Components: Plugins + OSGi
Environment:
Resolution: Fixed
Added: 11/08/2016 15:06:20
Affects Version: 6.2.0
Fixed Version: 6.2.0
Server:
Platform:
Related Issues: None

Win a Ticket for Velocity Conference New York, 2016

^CEFA8E2DA47B88FCBCC79DF6D23A5B674F16EC5A907ADE94F3^pimgpsh_fullsize_distr

For the second time we are sponsoring Velocity Conference, New York. You can visit us at booth #19, we will be showing off the latest version of FusionReactor and FusionCLOUD. To celebrate this we are giving away a free ticket for Velocity Conference, New York.

The Prize is for one Bronze 2-Day Pass which Includes:
– All sessions (Wed & Thu)
– All keynote and plenary presentations
– Sponsor Pavilion and all events held there
– All on-site networking events
– Lunch (Wed & Thu)

There are Two ways to enter the draw:
1) ON TWITTER : Retweet this tweet and follow us it is that simple! If you are already following us then just retweet this.

OR (You can do both to double your chances of winning).

2) ON FACEBOOK : Just Like us on Facebook –  and post us a Personal Message – “I want to go to Velocity New York”
We will be announcing the winner on,  Friday 26th August, this will give the winner enough time to organise flights and accommodation.

If you do not win, please do not worry you can still save 25% on the entry price by using our Discount Code: FusionReactor25

 

Announcing FusionReactor 6.2

We’re happy to announce the latest release of FusionReactor – 6.2.   This release contains around a dozen cool new features and improvements.   You can see a list of all the new stuff on the Release Notes page or simply just go and download it here.

One of the most interesting new features is the Applications View.   Users who are familiar with FR6 will have already taken note of the new capability to filter requests and transactions on Application and lower level categories, which we call “flavors” and “subflavors” – the bottom line is that for Web Requests, we may have Web as the flavor of the request and then subflavors would be the HTTP methods of the Web Request, such as – GET, POST etc.

Why is the useful ?   Well the Applications View can now give you a great visual breakdown of how much each of those requests are effecting your application – in terms of processing time and hit counts.   You can see this from the image below.

Applications View

Using the time filter, you can easily take snapshots of time to see how your applications are being utilized. This is great for identifying potential performance bottlenecks. This view also provides some interesting details, showing breakdowns of memory used, duration (compared with average duration), hits and errors generated via that call – plus the amount of CPU used (in ms).

Application Detail View

Production Java Profiler Extensions

FusionReactor 6 Ultimate Edition now includes a Production Profiler for Java, which is designed to help you identify bottlenecks in your production environment. The Production Profiler is VERY low overhead, so you gain maximum benefit, without impacting your applications.

A new feature in the profiler is to enable On-Demand decompiles as well as integrated Debug Triggers to be set directly from the Profile Page.   This is another example of how easy it is to get to the root of your issues using FusionReactor.   Links to the Decompiler and Debugger are highlighted in RED and GREEN respectively.

Java Profiler

Last, but not least… FusionCLOUD

One of the most significant things is that 6.2 is actually our official FusionReactor agent release for FusionCLOUD.

Most of you will be saying – FusionCLOUD – what’s that…?   Well, we’ve been running FusionCLOUD as an invite only beta for around 12 months now.   FusionCLOUD is our exciting new service which extends the on-premise version of FusionReactor to add a broad range of extended functionality available via the cloud.

So what will FusionCLOUD have to offer…?

  • Many of the features you’re already familiar with in FusionReactor, such as Running Request, Stacktraces, Web Metrics view, Resources View
  • CLOUD Dashboard – similar to Enterprise Dashboard but very configurable, with extended views and sophisticated threshold setting
  • Secure Bi-directional channel (SOCKET) – ability to send requests down to your server from FusionCLOUD e.g. launch a Stack Trace / Garbage Collection / Execute script
  • Application view – the app view provides FR users with the insight into how your actual application is performing – not just web requests or transactions as we have in FusionReactor.
  • Alerting Engine – with full integration to alert with emails, PageDuty, HipChat, Email, Slack, OpsGenie , VictorOps, FLOWDOCK, Twilio, IRCCAT etc.

FusionCLOUD Request Throuput
If you are interested in getting some more information on FusionCLOUD or would like to jump onto the FusionCLOUD Early Bird program – please contact sales

FusionReactor features in the DZone Performance & Monitoring Guide

FusionReactor features in the DZone Performance & Monitoring GuideDZone have just published the 2016 Performance & Monitoring Guide and FusionReactor are featured in it. According to DZone’s research, it states that the #1 tool for finding production issues is APPLICATION LOGS (90% of respondents) – which we think is pretty SAD – because delving through logs is painstaking, time consuming and generally not very much fun.

So why are traditional APM tools not solving this issue?

Well, your typical APM tools provide some neat metric graphs and can alert you when something seems wrong, but they don’t tell you much at the level of detail software engineers need to get to the actual root of the issue. So you end up having to grep through logs, dive into the heap, tally your object instances, run stack trace over and over, guess some breakpoints or include debug data into our code (WOW – things are REALLY BAD).

When something breaks in production, developers must go deeper than resource usage or business transaction fail rates – they need real-time insight and transparency into what the application is actually doing at the point that it’s breaking – in production.

In order to pinpoint issues in production we believe developers need additional tooling which is actually closer to what they would use in their development/test environments. Developers need to see things like:

  • stack trace and local variable visibility, at the exact point of failure or deadlock
  • profiling information, when code is run against ‘real production data’ – so that performance bottlenecks can be identified
  • transactions, web and JDBC requests not just measured by time, but also by the amount of memory consumed
  • class loads/unloads & memory allocation (heap + non-heap) across time

FusionReactor Ultimate Edition is designed to give the level of detail software engineers need to get to the actual root of the issue and provides low-overhead production-grade tools to give access to detailed information needed to “deep-dive” & quickly figure out the hard stuff developers need to fix. FusionReactor doesn’t “just monitor” and put the burden on you to figure things out. FusionReactor puts you in control, so that you can instantly isolate production issues and performance bottlenecks with our integrated low overhead Production Debugger and Java Profiler. Plus, it will pro-actively improve application resilience with our unique Crash Protection capability.

No other monitoring solution gives you the same level of depth, insight or control of your Java applications ‘in production’.

If you’re not using Fusion Ultimate Edition already, please contact sales and we would be happy to provide you with an Ultimate Trial license – or if you’re new to FusionReactor, just download our 14 day Free Trial

Introducing FusionReactor’s Production Java Profiler

If you’re trying to root out application performance bottlenecks on your production JVM environment – then you are faced with some significant challenges.

Knowing where and what to tune up within your applications can be a major headache. APM tools can help and generally they provide metrics which will highlight slow running queries or poorly performing requests. However, what if you’re looking for performance issues within your actual code – you know it’s performing poorly – but you want to understand exactly how slow and then figure out why!

For performance issues, (unless you’re already using FusionReactor!) you may think of using a profiler, such as JProfiler or jvisualvm. However, it’s not easy to attach such tools to a specific process (especially in production) and it’s common knowledge that such tools impose a heavy performance burden themselves which essentially will render them useless in a production environment.

We now have an alternative – FusionReactor’s Production Java Profiler.

FusionReactor 6 Ultimate Edition now includes a Production Profiler for Java, which is designed to help you identify bottlenecks in your production environment. The Production Profiler is VERY low overhead, so you gain maximum benefit, without impacting your applications. The profiler may be run on demand, but is switched on by default, so that it will automatically profile your application as soon as it detects a long running request or transaction. You can also limit the number of profile samples which are taken, which will enable you to control the level of accuracy of the sample. Our tests have shown that even with limited samples, the insight you gain into performance bottlenecks is invaluable.

What can you profile?

Any requests or transactions which are running on the JVM – e.g. Tomcat, JBoss, WildFly, Glassfish, Jetty etc. ColdFusion applications can also be profiled– as well as any other applications which are currently being monitored by FusionReactor 6.1 or higher.

What do you have to do to start profiling?

Install FusionReactor 6.1 or above – activate it using either a TRIAL license, or your own FR Ultimate license – and that’s it. The Production Profiler is automatically configured to immediately profile any request or transaction which runs longer than 3 seconds. The default profiling sample is 200ms.

You can also prProfiler Iconsofile individual requests by simply clicking on the Profile now button – indicated by the Clock icon – which you can see next to any running request.

As requests are profiled, they will be listed in the Profiled requests or transactions screen – as in the example below.

Profiled Transactions WebRequest

Clicking on the Profiler link, will take you to the Profiler details page – which shows a breakdown– represented in time and percent of how long was spent in specific sections/areas of your application code. The profile taken is basically an inverted view of the call stack.

Profiler

Bottlenecks are generally easy to spot. In our opinion, optimizing every part of your code is not worth the effort. Efforts should be focused on code segments where returns are higher, or rather highest.

Features and Benefits

  • When FusionReactor Ultimate is running, then profiling will start automatically for any request/transaction which runs for longer than 3 seconds. Note that this threshold can be easily altered to suit your needs.
  • Profiling can also be started on demand.
  • Find the root cause of performance bottlenecks in your application by viewing the profiled call stack in a top to bottom view.
  • Performance is shown in terms of time spent within that method – shown in seconds. The time will also be shown as a percentage.
  • Profile anything that runs on the JVM – without having to make any Java command line changes or restarting any processes – everything is built into FusionReactor Ultimate Edition.

If you would like to evaluate FusionReactor Ultimate – please download a trial license here

Transaction Memory Values Explained

One of the metrics gathered by FusionReactor during the execution of a transaction (request) is the memory usage of the transaction. This is displayed on the Main tab in the transaction details page. Since FusionReactor 6 we have added the Transaction Allocated Memory value to these details. All of these numbers can be a little confusing so below we have explained what all the memory values mean.

Explaining FusionReactor Transaction/Request Memory Values

The first few numbers are quite straight forward. These are simply a snap shot of the JVM state at either the start of the transaction (for transactions that are still running), or at the end of the transaction (for transactions that are finished).

Used Memory

This is the amount of memory that is currently used by the JVM, shown as both a absolute byte value and as a percentage of the maximum memory.

Max Memory

This is the maximum amount of memory that the JVM is allowed to use. This can be defined using the -Xmx Java argument.

Total Free Memory

This is the actual amount of memory that is not used by the JVM, this includes memory that has been allocated but not used yet. i.e. this is max memory minus used memory.

Allocated Memory

This is the current amount of memory that has been allocated by the JVM.

Free Memory

This is the amount of memory that has not been allocated by JVM. i.e. max memory minus allocated memory.

Transaction Allocated Memory

This value needs some deeper explanation in order to avoid confusion. This number is the total number of bytes that have been allocated during the life time of the transaction. Every time an object is created a portion of the JVM memory is used to hold this object, of course in java the garbage collector (GC) will automatically free any memory that is no longer needed.

This means that you can the reuse the same memory space again. So if we run the bit of code below, we will allocate memory space the string 10 times. Resulting in the transaction allocated memory value being 10 times the size of the single string.

for(int i = 0; i < 10; i++)
{

String str = “this is a string”;

}

This would mean that even if you have a max heap of 8 gigabyte the transaction allocated memory value can exceed this value. This would indicate that JVM is allocating and then freeing lots of object. If we look at the image below you can see that a single transaction can allocate more than the maximum heap, as long as it does not do it all in one go.

Transaction Memory Vales 2