Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

XRebel 2.1 Released: Tracing asynchronous invocations for more insight

Hello everyone! We just released a new version of the lightweight Java profiler, XRebel with a few important improvements. With XRebel 2.1 you will be able to trace asynchronous invocations for applications that spawn threads via Thread or ExecutorService API. You will also be able to better understand the results since we have added rendering of the aggregated database queries into the application profiling view.

Download XRebel 2.1

Tracing asynchronous execution

It often takes more than one thread to handle an HTTP request in a web application. Database access, communication to external services, and other time consuming computations may be more efficiently handled in separate threads.

There are different approaches to thread management and different APIs may be used to start a new thread. Some obvious choices for working with threads in Java: Thread API, ExecutorService, ManagedExecutorService, EJB asynchronous method invocation.

With the latest version of XRebel, you will be able to trace asynchronous invocations. You will be able to view the profiling results for individual traces attached to the main HTTP thread call tree.

Here is an example that explains how asynchronous invocations are handled by XRebel. Consider a scenario where the database access operation is offloaded to a separate thread using the ExecutorService API. The spawned thread will pull in the records from the database and return to the HTTP thread which is blocked on a Future.get call.

ExecutorService executor = Executors.newSingleThreadExecutor(...);
...
Callable<Collection<Owner>> callable = new Callable<>() {
   @Override
   public Collection<Owner> call() throws Exception {
       return clinicService.findOwnerByLastName(owner.getLastName());
   }
};
...
Future<Collection<Owner>> future = executor.submit(callable);
...
final Collection<Owner> results = future.get();

The asynchronous execution trace is rendered in the same call tree as the HTTP thread by attaching the results to the blocking call. In this example, 63.2% of the total time was spent on blocking and waiting on the thread that was going into the database.

image00

Aggregated database queries in application profiling

You probably know that we added the application profiling view in XRebel 2.0. The application profiling view gives you the ability to measure and display the performance of Java code. We noticed that the profiling report, in some cases, displayed that the last call in a rendered branch accumulates a reasonably high percentage without any further breakdown. This happens when database queries are executed.
In XRebel 2.1 we added rendering of the aggregated queries in application profiling view. It makes the results more intuitive and easier to understand as to why the last call in the subtree accumulated a higher percentage.

13.8% was spent in Loader.getResultSet method call because of the 13 database queries.

image01

Improved threshold alerts

The XRebel toolbar displays an alert icon whenever a certain threshold is exceeded, like when a request execution is too slow or when too many queries are executed during the request.

A nice little improvement for the threshold alerts that we added in XRebel 2.1 is the alert icon for the individual HTTP request when a corresponding threshold is exceeded.

image02

Having the list of the results rendered in the same view it is now easier to locate the requests that exceeded the threshold.

Pretty cool enhancements there! XRebel 2.1 is available for download.
Download XRebel 2.1

Give it a try and you will absolutely love it! Don’t hesitate to give us your feedback in our forums and give us a shout-out on twitter as well, don’t forget to use the #xrebel hashtag!