The last post in our Profiling in Production series we covered instrumentation and sampling profilers. We talked about “resources of interest” but which ones are the most useful for diagnosing performance bottlenecks? The most commonly used resource is time. We’ve been deliberately vague about the concept of timing so far because when it comes to computers there’s actually two types of timing..

In this blog post we’re going to look at performance profiling. What it is and how it works. This is the first post in our series on Profiling in Production, by the end of the series you’ll have an understanding of how profilers work, which ones are safe and efficient in production, how to read and interpret the data they produce and finally, how to use this knowledge to keep on top of performance.

When TransferWise first started using Opsian’s Continuous Profiling platform they had a service with a peculiar and elusive performance problem, one that had stumped existing performance monitoring tools. This post covers the symptoms of the mysterious problem and how TransferWise used Opsian’s tools to track down and solve it.

If you’ve ever struggled with optimising Java’s Garbage Collection performance in production then our newest feature, Continuous Allocation Profiling, is the tool for you. It breaks down allocations by type and by line of allocating code, live from your production environment to give you all the information you need to optimise the parts of your applications with excessive allocation behaviour.

The JVM’s garbage collectors make use of Thread-Local Allocation Buffers (TLABs) to improve allocation performance. In this article we’re going to understand what TLABs are, how they affect the code generated by the JIT for allocation and what the resulting effect on performance is. Along the way we’ll learn about the organisation of CPU caches and how multiple CPU cores keep their contents coherent and how you can use this knowledge to avoid multithreaded scalability bottlenecks.

The use of Docker and Kubernetes has been growing in the JVM community over the past couple of years. One downside to Kubernetes from a performance optimisation perspective is that it can be harder for developers to get profiling data from their production environment. This blog post aims to show you how to make that easier by continuously profiling using Docker and Kubernetes.

The HotSpot JVM comes with a range of non-standard -XX: options, many of which have an impact on performance. One set are the family of so-called AllocatePrefetch options comprising: -XX:AllocatePrefetchStyle, -XX:AllocatePrefetchStepSize, -XX:AllocatePrefetchLines, -XX:AllocatePrefetchInstr, -XX:AllocatePrefetchDistance and -XX:AllocateInstancePrefetchLines. In this blog post you’ll learn the background behind why AllocatePrefetch is necessary and how it can help performance.

Performance testing is hard and there is no one established practise for doing it. In this article you will see a simple Spring Boot Rest endpoint that exhibits a performance issue, how to load test it and how to use profiling to identify and resolve the bottleneck.

In this screencast we're going to show how to solve blocking and locking performance problems using the Opsian Continuous Profiling service

We’re pleased to announce that Opsian now supports Continuous Profiling on the GraalVM JVM - this means that GraalVM users now have access to the same always-on low-overhead performance data as users of OpenJDK-based builds.