Jan 25, 2013

Profiling Grails Applications With VisualVM

Lately, I have been finding the need to get into the bowels of Grails in order to increase the performance of large batch type features of any application. Most of the time the issue appears to be with the Hibernate session becoming over-saturated with references. Performance degrades significantly even when limiting the batch size to ~100 records. Luckily, Oracle ships a pretty decent profiler with Java, VisualVM. The trick is getting it to work correctly with a Grails application.

Here are the tricks, I’ve found

  1. Add the command ‘-Xverify:none’ to your GRAILS_OPTS environment variable before launching your application. VisualVM relies on class replacement to instrument your code for profiling, and this switch allows that to work correctly.
  2. Disable the auto reloading agent in Grails by passing -Dauto.recompile.disable=true on the command line when you start your Grails application. This mostly a safety measure. Since VisualVM is replacing classes, you don’t want Grails replacing over the top of them. Also, there is a significant performance hit when using the Reloading Agent once it recompiles any class since it it basically proxying every class reference.
  3. Launch VisualVM with a bunch of memory. Since Grails needs a good chunk of memory, the profiler is going to need a lot. You can increase memory to VisualVM by passing the commands -J-Xms<memory size> and -J-Xmx<memory size> on the command line when launching VisualVM (i.e. jvisualvm -J-Xms1G -J-Xmx1G).
  4. While your there, you should add your Grails application classes to VisualVM’s classpath so you can make better sense of the profiling results. You can prepend/append classes to VisualVM’s classpath by using the –cp:p and –cp:a arguments, respectively (i.e. jvisualvm -J-Xms1G -J-Xmx1G –cp:a <path to grails app>/target/classes

About the Author

Object Partners profile.

One thought on “Profiling Grails Applications With VisualVM

  1. The correct is: -Ddisable.auto.recompile=true

  2. Robert says:

    Would be great if you provide a best practice pattern for “Do not profile class” settings in the Profiler, as it takes ages with the default settings to instrument all classes before you can start testing. E.g. org.springsource.loaded.* is one candidate to narrow the scope. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Managing your Helm deployments with Helmfile
As we’ve been using Kubernetes to build software delivery platforms for our clients, we’ve found Helm to be a reasonable solution to templating and managing deployments to Kubernetes.  Although templating alternatives such as Kustomize have […]
AWS CodeBuild Test Reports for Gradle builds
Although AWS documentation has instructions for adding Test Reports for a maven build they currently lack instructions for a gradle build. You can find the maven instructions here: https://aws.amazon.com/blogs/devops/test-reports-with-aws-codebuild/ Assuming you have your gradle wrapper […]
Structuring SwiftUI Previews for API Calls
SwiftUI, together with Combine and Xcode 11+, provide a powerful toolset for quickly creating an app with a native UI. In Xcode 11+, the preview pane was introduced in order to provide live snapshots of […]
Seamlessly Integrating Micro Apps with iFrame
A recent client wanted to upgrade a small portion of their legacy application with a more modern UI and extra functionality, like fuzzy text search. There are a few approaches to incremental upgrades of legacy […]