In Part 1 of this series, we covered the basics of creating a JMH project and getting it to run, proposed a small benchmark, and showed what the implementation would look like. In Part 2, we looked at how to configure JMH, how it works, and why certain parameters are necessary. In this last part, we'll focus on how not to write a benchmark for JMH and why some precautions are necessary. This may be the most important part of the three, as it'll give you insights into some quirks of the JVM.

In last week's blog, we discussed the basics of creating a JMH project and getting it to run. We also proposed a small benchmark and showed what the implementation would look like. Today, we'll be looking into how to configure JMH, how it works, and why certain parameters are necessary. (Be sure to join us next week for tips on how not to create benchmarks!)

You have an application running. It's doing pretty well, except for the fact that it's somewhat slow. You have identified the bottleneck, and now you're trying to come up with the ideal solution. There are a myriad of mechanisms you could try, but you don't want to deploy each one of your attempts to the development environment and then check the performance there. And running the application locally might not be the ideal solution either. So, what do you do?