Comments on: Which JDK to Choose on Kubernetes

By: piotr.minkowski

piotr.minkowski — Fri, 12 May 2023 08:11:52 +0000

In reply to Songkiet Pombuppa. No, I'm not using alpine. Yes, but you can as well use alpine for all other JDKs.

By: Songkiet Pombuppa

Songkiet Pombuppa — Thu, 11 May 2023 04:16:32 +0000

Are you using the ‘alpine’ version of each JDK?
Currently I am using Openj9-alpine, which I think it is the best in term of less memory, startup.

By: piotr.minkowski

piotr.minkowski — Mon, 20 Mar 2023 15:11:58 +0000

In reply to Raymond. Thanks for that suggestions. Maybe I'll be back once again to that topic - to add your suggestions and several other

By: piotr.minkowski

piotr.minkowski — Mon, 20 Mar 2023 15:10:01 +0000

In reply to Gary DeVal. Ok. Thanks for the suggestions. Yes, I did some warmups before starting tests (usually 1-2 minutes with avg traffic). Then 3x90s tests

By: Gary DeVal

Gary DeVal — Mon, 06 Mar 2023 19:26:45 +0000

For a throughput comparison to be meaningful, CPU usage needs to be accounted for somehow. For example, if system A handles 500 req/s at 30% cpu-util, and system B handles 500 req/s at 70% cpu-util, reporting A and B as equal in throughput is misleading; system A is probably capable of higher throughput than system B.

Measured throughput can be normalized for CPU consumption by driving enough load to saturate the CPU (cpu-util ~100%). If that is not possible, at least the CPU consumed by each system during the load test should be reported, and throughput can be normalized by dividing req/s by the cpu used; in the preceding example, system A’s normalized throughput would be (500 / 0.3 =) 1667 req/s, while system B’s would be (500 / 0.7 =) 714 req/s.

~~~~~
Java systems also depend on Just-In-Time (JIT) compilation of heavily used methods to improve throughput. The system needs to be run under load for some time to allow the JVM’s internal profiler to identify hot paths and the JIT compiler to optimize the busy methods.

So for a throughput measurement of a Java system, load should be applied twice: first for a “warmup” period to let the JIT compiler do its job, followed by a “measurement” period, the results of which are reported as the throughput of the system. A warmup period of 5 minutes (under heavy load) is typically sufficient for JIT to do most of its optimization work; after the warmup load terminates, apply measurement load for 2-3 minutes to get a realistic view of the JDK’s performance.

By: piotr.minkowski

piotr.minkowski — Tue, 21 Feb 2023 13:54:35 +0000

In reply to peterreji. From my perspective, if you use alpine with jre it's fine. if there are less vulnerabilities than in standard openjdk image it is even better

By: peterreji

peterreji — Tue, 21 Feb 2023 02:37:37 +0000

how about using an alpine image and install jre on top of that and use that image as the base image? from ECR scanning, i noticed that the vulnerabilities were zero on the alpine+jre combo whereas there were more than 60 vulnerabilities in the openjdk image. please let me know your thoughts

By: piotr.minkowski

piotr.minkowski — Mon, 20 Feb 2023 22:16:35 +0000

In reply to vaano94. Yes, for example, Azul or OpenJ9 provides some features for decreasing startup time. Maybe I create a similar article in the future with a deep dive. For that article, my idea was to compare all the distros with the same JVM flags

By: piotr.minkowski

piotr.minkowski — Mon, 20 Feb 2023 22:08:17 +0000

In reply to Tilo. I would do it, but there is no Red Hat OpenJDK in Paketo buildpacks.

By: piotr.minkowski

piotr.minkowski — Mon, 20 Feb 2023 22:07:42 +0000

In reply to Fra. In the article, I didn't test it. However, in my tests after the article, I set `-Xquickstart -Xshareclasses:cacheDir=/cache` with mounted volume and startup time was significantly improved from ~9s to ~4-5s. I also tried to enable CRIU support, but on Kubernetes it may be quite, so I avoided it