Since version 3.1, the Spring framework offers an abstraction towards several different sources through which you can easily configure your application: the Environment.
In this post I describe a micro benchmark that I ran to prove that, while it’s a convenient API if you’re using Spring in your application, it might introduce a performance penalty for which you should not use it outside of your initialization code.
How it works
Before getting into the numbers, a quick digression on the internals of the Environmentthat are important to this post.
From the documentation:
Properties play an important role in almost all applications, and may originate from a variety of sources: properties files, JVM system properties, system environment variables, JNDI, servlet context parameters, ad-hoc Properties objects, Maps, and so on. The role of the environment object with relation to properties is to provide the user with a convenient service interface for configuring property sources and resolving properties from them.
So, you can use the Environment to have a common interface to properties provided with different strategies, using a simple getProperty call to access the required value. Look at the following Groovy code:
@Component
public class Greeter {
private Environment environment
@Autowired
public Greeter greeter(Environment environment){
this.environment = environment
}
def nickName(user) {
environment.getProperty("user") // here be magic
}
def greet(user) {
def nick = nickName(user)
if (name == null) println "Hi, ${user}!"
else println "Hi, ${nick}!"
}
}Now, I can specify nicknames in a properties file so that I can greet know users with a more familiar nick name, still being able to salute also users which are not given a nickname. Neat, but how about performance?
Now, I can specify nicknames in a properties file so that I can greet know users with a more familiar nick name, still being able to salute also users which are not given a nickname. Neat, but how about performance?
The hidden Exception
I got into this exercise while debugging a couple of slow pages in the website I’m working on: the destinations pages of the KLM main site. While performance is generally satisfactory, two pages were constantly giving above second response times. Definitely too much.
In our code, we were translating some country names into queriable keys for an external services. We also needed to override an otherwise straightforward translation algorithm with very specific exceptions to the rule. The actual code was pretty much like the above Greeter.greet(user), and a Flight Recorder session eventually provided us with the performance bottleneck (click to open):
For 12 page refreshes we were silently throwing 140k+ exceptions. And exceptions are sloooooow, even if you just create them.
Looking at the top thrown exception, it was actually pretty easy to understand what’s going on: the Environment checks whether the requested property is defined in the current JNDI context. But, if the name is not found, a NameNotFoundException is thrown. In our specific case we were using property lookup for exceptional cases, which means the vast majority of cases resulted in an exception being thrown.
Micro benchmark
I put together a micro benchmark to evaluate the potential performance gain of the original property lookup strategy versus a simpler one where relevant properties are loaded up at class construction time. I used the Java Microbenchmark Harness, which does an incredible job at making micro benchmarks easy on the JVM: JIT, warm up, class loading, all is taken care of for you and you can just go ahead and put your code under test. Here the results (higher numbers better):
[Property lookup per invocation]
Result: 28917.876 ?(99.9%) 183.630 ops/s [Average]
Statistics: (min, avg, max) = (25688.067, 28917.876, 30976.876), stdev = 777.500
Confidence interval (99.9%): [28734.246, 29101.505]
[Property loading at class construction]
Result: 159062.900 ?(99.9%) 1013.309 ops/s [Average]
Statistics: (min, avg, max) = (138707.926, 159062.900, 177183.549), stdev = 4290.413
Confidence interval (99.9%): [158049.591, 160076.209]
As expected, five times as fast.
Conclusions
I’m not a big fan of Spring, but if you’re using it the Environment class is a dead easy interface to your application configuration. But, unless you’re using JNDI as your main store of configuration properties, its performance characteristics make it a great tool only if you’re using it in your initialization code, and not during on-line processing of requests.
| Reference: | Spring Environment is for initialization code only from our JCG partner Carlo Sciolla at the Skuro blog. |
