The setup

Most of the needed packages were already available in yum package manager, the installation process was smooth and the installed components worked out of the box. For PostgreSQL, unfortunately, the default yum package is quite outdated (v9). You need to use the Extras catalog to get the version 10.

For Java JDK, since we use OpenJDK we decided to use Amazon Corretto 8, strangely enough and unlike Amazon Corretto 11 the version 8 is not included in the package manager. So we installed manually the AARCH64 version (again everything worked as documented). After installing nginx, preparing a test database, and configuring the remaining dependencies we were ready to test the setup

After starting the services, the first thing that I noticed was the horrendous startup time of Java applications. It was unbelievably slow, almost an hour to start the application! for sure I know that it can takes a couple of minutes to start this complex monolithic backend, but if it takes an hour there is something wrong with the setup.

After some sanity checks I couldn’t figure out the root cause of the problem, after calling for assistance from our team, they quickly identified the issue: dev/random runs out of available entropy. The app was waiting for /dev/random to provide randomness and /dev/random typically blocks if there is less entropy available than requested. They suggested that I switch to /dev/urandom as the source of cryptographic randomness. A call to cat /proc/sys/kernel/random/entropy_avail returns values in the range 70-100. We switched to /dev/urandom and now we have a more reasonable boot time (under a minute)!

Excerpt from /usr/lib/jvm/amazon-corretto-8.265.01.1-linux-aarch64/jre/lib/security/java.security

Maybe the Amazon Corretto for AARCH64 distribution shoud use /dev/urandom by default?

Benchmarking with Bombardier

The objective is to determine whether the performance of this Graviton2 based VM are quite competitive. In order to have a baseline, we created an x86 VM with equivalent characteristics (but +27% of the price).

Since the two VMs have the same OS, we used the exact same scripts to install the dependencies, to deploy the apps and to benchmark it using Bombardier!

Bombardier is a HTTP(S) benchmarking tool. It is written in Go programming language. We compiled it on both VMs.

We designed 8 production workloads, involving database CRUD, data indexing, search and data encryption and transfer. For each payload we performed 10 tests and picked the median, after each iteration we restarted the jvm.

Conclusion

I should admit that I’m pleasantly surprised with the performances of the ARM version of OpenJDK.

As with any small-scale benchmark we should take it with grain of salt, but we will definitely perform more extensive tests in the upcoming week.