If you ever had some serious issues with the performance of your Java application, most probably you know how valuable thread profiling can be. But do you know which profiler you should use?
There are two basic techniques used by profilers – sampling and instrumentation.
A sampling profiler involves periodically asking the JVM for the current point of execution of all currently alive (active) threads. This type of profiler carries the least amount of overhead. This is important because introducing heavy measurement/instrumentation into the application can change the performance characteristics significantly. Using a sampling technique, we get a snapshot of the next stack trace when the timer fires. So the profiler looks at each thread and determines which method the thread is executing at that moment. As there are gaps between consecutive measurements, sampling profiler achieves a trade-off between the level of accuracy obtained vs the overhead involved in actually taking the measurement, This is illustrated in the following figure:
As you can see, the thread spent most of its time in save method and a little bit in read method. If the sampling happens only when the thread is in a save method (more probable as this method dominates), the profiler will report that the thread spent 100% of its time in save method, which is of course not accurate.
A rather logical way to minimize this sampling error is to reduce the time interval between sampling and increase the profiling time. However, as we discussed earlier, this solution might impact the performance characteristics of the application, so a balance is the key.
Instrumented profilers introduce a much larger performance overhead into the application. This method usually involves injecting bytecode into the classes for the purpose of profiling. This approach involves a higher performance impact, but generates a more accurate measurement when compared to the result from the sampling profiler. Another problem which may arise as a result of the way an instrumented profiler modifies the bytecode is the following; as you may know, JIT compiler inlines small methods. Because the instrumentation introduced by the profiler, some small methods might not be eligible to be in-lined anymore. It can have a serious impact on application performance. If you decide to use instrumented profilers, make sure that you instrument only a small section of the code.
Profiling in a development environment is easy. However, it might not be enough. When dealing with production data, we are exposed to a different scale and thus, we might observe different bottlenecks in our application. That’s why profiling in production is so important. As already mentioned, both sampling and instrumented profilers have their pros and cons. If you want to profile in a production environment, a low overhead sampling profiler seems to be a better choice. FusionReactor’s Production Code Profiler will help you identify bottlenecks in your production environment with a very low sampling overhead. The really cool thing about this profiler is that it can be configured in a way that it will automatically profile your application if it detects a long-running request or thread. What is a long-running request? It’s up to you to define, but 3 seconds is the default value. If you monitor some sort of latency-sensitive application, then you might want to decrease this value. Similarly, if your application performs some time-consuming computations, then most probably you don’t want to be notified all the time and increasing Minimum Transaction Time will be necessary. Taking a stacktrace snapshot takes as little as 1 ms per sample. With a default sampling rate of 200 ms, you can usually get some meaningful results from just 5 samples.
FusionReactor’s thread profiling output looks like this:
On the left-hand side, you can see the percentage of time the particular method took. On the right -hand side, time in seconds is shown. As you can see in the output, logging in lowCostSearchEngineClient class can be a potential bottleneck in this application. Thanks to the bundled de-compiler, you can instantly check the method by simply clicking on it.
It’s not always easy to pinpoint a performance issue in a running application, but profilers are usually good estimators. Sampling profilers such as FusionReactor’s Profiler, are perfect tools to use them in a production environment.
We are thrilled to announce that for the second year in a row FusionReactor has been accredited with the “FeeFo Gold Trusted Merchant” 2018 award!
Feefo is an independent feedback service that are dedicated to collecting trusted reviews. The Gold Trusted Merchant award is only given to businesses that have an average positive Service Rating of between 95% and 100%.
The whole FusionReactor team would like to thank everyone who filled out feedback for us – we really appreciate it!
The award shows that FusionReactor is a leading tool for Java Application Performance monitoring & Degugging – designed to help Developers and Devops improve their applications and get to the root of the problem as fast as possible.
Using the Feefo feedback service has been a fantastic way for us to see how FusionReactor is being utilized by our customers. As well as highlighting any issues they may be facing. We always aim to provide the best possible service for our customers.
“The Trusted Service award is a recognized symbol of trust – helping customers click with confidence.”. From everyone on the FusionReactor team thank you and have a great year!
“We’ve made a new screencast that shows an introduction to FusionReactor Cloud, a new way to monitor any number of servers in a consolidated interface that can scale up and down with your infrastructure. Not only do new servers automatically register and deregister themselves with the Cloud dashboard, but it supports a pay-for-what-you-use model that prevents you from locking into a specific number of licenses.
This is a great fit for deployments like Docker Swarm where you can scale your service up and down from day to day. In this demo, I’ll show you how to add FusionReactor cloud easily into any CommandBox-based server and show how to deploy it to a Docker Swarm on our Ortus Docker image and then play around with it.” Brad Wood, Ortus Solutions (Follow him on Twitter)
The FusionTeam will once again be PLATINUM sponsors of this great event – make sure you join us and the Adobe ColdFusion Team in Las Vegas!
We will be showing off the new major release of FusionReactor, which is FR 7 as well as FusionReactor CLOUD.
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:
OR (You can do both to double your chances of winning).
The winner will be announced on : Friday 27th October
If you do not win, or you just want to sign up right away, you can get a reduced price ticket for just $249 by using our registration code: CF17OFFER249 when you purchase a ticket here
FR7 represents a massive step forward for FusionReactor, includes 20 completely new core features and around 100 major improvements and bug fixes. Our primary goals for this release have been to enhance the array of system, application and JVM metrics available, as well as build upon and extend the core functionality within FR Ultimate Edition.
Our mission is to provide developers, DevOps and I.T. professionals unparalleled depth of insight, transparency and interpretation into what applications are doing at the point where things are going wrong! Why? So, that they can isolate issues and performance problems faster than with any other tool.
FR7 has significantly increased the array of supported metrics available. Ranging from complete JMX MBean metrics, to enhanced framework (ColdFusion and Java) support to NoSQL data stores and current streaming platforms, such as Apache Kafka™.
The other major focus of this release has been to enhance FR Ultimate Edition – which adds a completely new definition to the meaning of application monitoring. FR Ultimate combines the most useful components and features from the most used error detection and performance analysis tools available to developers: the code debugger, application profiler and with the launch of FR7, the memory profiler. These tools can all be used safely, securely and most importantly with MINIMAL OVERHEAD in your production environment.
The complexity of today’s distributed, service based, containerized, ephemeral environments, combined with unprecedented quantities of data means that re-producing production issues is virtually impossible. The error detection features built into FR Ultimate completely change how issues would be investigated, removing the need to try and reproduce defects in a test environment or scouring through log files in the hope of finding a clue. FR Ultimate enables you to interact with issues as they unfold, directly in production. It is the only product on the market which offers such capabilities.
The whole team is extremely proud of FusionReactor 7 and we hope that you enjoy using it and that it continues to be your #1 tool to monitor, detect issues and protect your applications and servers.
CEO Intergral – makers of FusionReactor
New in FusionReactor 7.0.0, we added the ability to monitor your applications usage of Apache Kafka.
Firstly, what is Apache Kafka. Apache Kafka is a publish-subscribe service that allows for multiple system to publish to a given topic and for multiple system to create from a topic. It is commonly used to build real time data pipelines because it is reliable, fast and scalable. To find out more about Apache Kafka visit there website: https://kafka.apache.org/
There are two major aspects of using Kafka the consumers and producers. In this post we are going to talk about how FusionReactor can monitor consumer applications.
When you start your application with FusionReactor (see Install Guide) we will automatically detect and start tracking calls to the Kafka brokers. These calls are then tracked into transactions and displayed in the Transaction History page.
These transaction track the topic that is being polled and the partition that was polled, as well as the number of records returned and the consumer group used. From these transactions we also graph the activity and execution time into the normal transaction graphs in FusionReactor.
In addition to the standard graphs in FusionReactor if you are using an Enterprise or Ultimate license you will also have access to the ‘Framework Source’ page this page will aggregate the Kafka metrics into a selection of graphs to show how the Kafka usage breaks down by, Broker, Topic and Partition.
When you have a Java application connected to Kafka, there are various metrics available from the driver library. FusionReactor is able to track these metrics and display them over time in a collection of graphs. FusionReactor provides two pages of these graphs Kafka Metrics and Kafka Node Metrics, each page is then displayed based on the selected consumer.
The Kafka Metrics page is intended to give a general overview of the state of the applications use of Kafka, so on this page you will see metrics including:
The Kafka Node Metrics include metrics for each consumer that is running in the JVM, split down to each node that is providing the data. These metrics include:
For more information about what these metrics are please visit the Apache Kafka documentation
DZone have just published the 2017 Guide to Java: Development and Evolution and FusionReactor are featured in it. The 2017 Guide to Java explores upcoming features of Java 9, how to make your apps backwards-compatible, a look into whether Microservices are right for you, and using the Futures API in Java.
You can download it for free from the Dzone website.
We are Sponsoring Velocity Conference, San Jose,CA 2017: Build & Maintain Complex Distributed Systems. Come and meet us at our booth #718. We will be showing off the latest FusionReactor developments and features to help Java developers fix problems faster! You can read more about our event attendance here.
If you cannot wait to meet us get started with a free trial of FusionReactor Java application Monitor or visit our webinars page to see FusionReactor in action. With both new webinars to sign up to and prerecorded webinars to watch.
David Tattersall the CEO of Intergral (makers of FusionReactor) talks on the ColdFusion Alive podcast with host Michael Smith. On Why It is Different to other APM tools and what is new in version 7 & the CLOUD