OpenJDK:JMH Simple Usage

Introduction

Few people have heard of JMH, yet if harnessed properly, can be a very valuable tool, typically when we come across performance considerations. Now and then we will come across a task that can be done multiple different ways but we are unsure which one is the best performing code. A quick JMH code over Java command line application can quickly tell you how is one code performing compared to the other.
What JMH does when properly coded is to take your piece of code and run it for multiple warm up iterations to clear the memory cache, and then run it again over X amount iterations to obtain the averaged benchmark result.

Elaboration

Using JMH

It is recommended to use JMH in the most simplest java way, ie using the old and standard public static void main:

public static void main(String[] args) throws RunnerException {
  Options opt = new OptionsBuilder()
      .include(JmhTestRun.class.getSimpleName())
      .forks(1)
      .build();
  new Runner(opt).run();}

Afterwards, we simply just need to create the Benchmark tests as simple as follow:
@Benchmark@BenchmarkMode(Mode.AverageTime)
public void benchmarkEqualIgnoreCase() {
  for(int i = 0; i < data.size(); i++) {
    if(data.get(i).equalsIgnoreCase("string500")) {
      break;    }
  }
}

Do note that since you want to test the function, in this example its the equalsIgnoreCase(), make sure that any data preparations is done outside the method or it will skew the benchmark result

Then just simply run the simple java class and JMH will start, it will iterate through to warm up before doing the actual benchmarking. After a while you will see the result:


As you can see, the result here is not clear, this is because we are benchmarking average time it takes to finish the operation, which is very very minute, therefore we should change it to Throughput and run it again, the result will be much clearer:


Finally we can conclude that the equal() is almost 7x faster than equalsIgnoreCase()

Using JMH on Spring Boot Application

It is possible to use JMH on a typical Spring Boot application, however due to the complex nature of Spring Boot application, in most cases, we will not get a clear benchmark result from it. I believe that JMH is not meant to be used to benchmark a Spring Boot application, or any complex client server based application, Gatling (https://gatling.io/) might be more suitable for such purpose.

Below is the result of running the same test above but in Spring Boot application:


As you can see there is no significant differences between equal ignore case and equal only executions in term of ops per second. This is simply due to Spring Boot background processes weighing way more heavily than a simple equal execution over 1000 samples.



Complete source code: https://github.com/overtakerx/jmhdemo



http://javadox.com/org.openjdk.jmh/jmh-core/0.9/org/openjdk/jmh/annotations/Mode.html
https://openjdk.java.net/projects/code-tools/jmh/

Comments

Post a Comment

Popular posts from this blog

Spring Boot 2: Parallelism with Spring WebFlux

Image
Spring Boot 2: Parallelism with Spring WebFlux Parallelism is rather unusual in Spring application, however when we encounter the need of HITLOL (HIgh Throughput LOw Latency), we need ways to make async calls. With Spring Boot 1, in high level definition, we can declare async on all the functions that are meant to be parallel and return Futures from there. Here is more detailed info:  https://medium.com/sipios/how-to-make-parallel-calls-in-java-springboot-application-and-how-to-test-them-dcc27318a0cf For Spring Boot 2, we shall employ Spring WebFlux libraries to accomplish parallelism. Mainly focused on functions: Mono.zipDelayError(), Mono.subscribeOn() and Mono.onErrorResume() The main function that drives the parallelism is zipDelayError(), the purpose of zipDelayError() as supposed to using zip() is to enable the other Monos to run to completion even if one Mono failed. AllDtos allDtos = Mono. zipDelayError (Arrays. asList (firstDto , secondDto , (Mono&l
Read more
Image
Implementing gRPC Using Spring Boot and Gradle Background GRPC (gRPC) is a RPC framework pioneered by google later on made public and open source. GRPC has not been officially supported by Spring Framework, so far there are few community libraries that can work seamlessly with Spring Boot. In this article, I will use the lognet's grpc-spring-boot-starter. Project Structure Ideally, the proto files for gRPC is located in another directory, which will then be accessed by the gradle plugin to auto generate the required files.   Gradle Script The heart of gRPC enablement lies on the grpc boot starter, which includes few other tasks outlined as below. https://github.com/overtakerx/grpcbootdemo/blob/main/build.gradle Few important note: first you have to run gradlew compileJava for the auto generation to generate the files from the proto file, then you will need to rebuild the project for Intellij to recognise the auto-generated files. Full demo: https://github.com/overtakerx/grpcbootdem
Read more

Cucumber + Junit5 + Localstack

Background What are the options to test an Amazon lambda that interacts with Dynamo DB locally? To be honest, there are several options, such as using Mockito, using stubs, swapping Dynamo DB with Mongo DB, however none of these truly replicate the amazon lambda and dynamo db ecosystem. Enter Localstack  ( https://github.com/localstack/localstack ), open source project that aims to emulate a local AWS cloud stack. With its docker version, we could spin up localstack and push our lambda and create our table in the dynamodb. To further increase its testing prowess, Localstack comes up with utils to integrate with Junit 4 and 5. Now we have the tools to create a BDD test using Cucumber, JUnit5 and Localstack as you can see below. Do note that due to the open source nature of localstack, it has several bugs that we manage to get around Prereq: Docker images: localstack/localstack:0.9.1 Note that the latest version of localstack docker image has bugs with the service port nu
Read more