Home » Java » Enterprise Java » More about Spring Cache Performance

About Nikita Salnikov Tarnovski

Nikita Salnikov Tarnovski

More about Spring Cache Performance

This is a follow up to our last post about Spring’s cache abstraction.

As engineers, you gain valuable experience by understanding the internals of some of the tools that you use. Understanding the behaviour of tools helps you become more mature when making design choices.  In this post, we describe a benchmarking experiment and the results which will help you understand Spring’s built-in annotations for caching.

Take a look at the following two methods:

@Cacheable(value = "time", key = "#p0.concat(#p1)") public long annotationWithSpel(String dummy1, String dummy2) {   return System.currentTimeMillis(); } @Cacheable(value = "time") public long annotationBased(String dummy1, String dummy2) {   return System.currentTimeMillis(); }

Here we have two very similar methods, each annotated with the built-in @Cacheable annotation from Spring Cache. The first one includes an expression written in the Spring Expression Language. The expression is used to configure how to calculate cache key using method parameters. The second one relies on Spring’s default behaviour which is “all method parameters are considered as a key”. Effectively, both the methods above actually result in exactly the same external behaviour.

We ran some benchmark tests, that allowed us to measure their performance:

Benchmark                       Mode  Cnt     Score    Error  Units CacheBenchmark.annotationBased  avgt    5   271.975 ± 11.586  ns/op CacheBenchmark.spel             avgt    5  1196.744 ± 93.765  ns/op CacheBenchmark.manual           avgt    5    16.325 ±  0.856  ns/op CacheBenchmark.nocache          avgt    5    40.142 ±  4.012  ns/op

It turns out that the method which had a manually configured cache runs 4.4 times slower! In hindsight, this outcome seems to make sense because of overheads. The Spring framework has to parse an arbitrarily complex expression and some cycles are consumed in this computation.

Why are we writing this story? Well –

  1. We care deeply about software performance.
  2. Our own codebase has a few of these instances where we have had to trade-off performance for zero benefits.

You should examine your code base and conduct a review or audit too. Jettison some of these instances as well and gain performance improvements. You could very well have some instances where you have manually configured cache keys as well. Remember, this is exactly the same behaviour that Spring Cache would provide you by default. A definite win-win situation!

Published on Java Code Geeks with permission by Nikita Salnikov Tarnovski, partner at our JCG program. See the original article here: More about Spring Cache Performance

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments