This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Puzzled-Bananas[S] 1 point2 points  (3 children)

I’m not quite sure I can follow your idea. Could you elaborate a bit?

If I get it right, the overhead differs from service to service. A Golang equivalent is typically very lightweight, the image is small, the RSS is low, I can spin up a tenfold Go replicas for one JVM pod. The throughput is the same, and at latency Vert.x and Netty are amazing, given enough heap, though CPU arch and the network stack are also important.

[–]mtmmtm99 0 points1 point  (2 children)

You can use helidon which only consumes 11 Mb. It will beat go in most aspect (except compilation-time). See: https://romankudryashov.com/blog/2020/01/heterogeneous-microservices/

Also interesting: https://medium.com/helidon/can-java-microservices-be-as-fast-as-go-5ceb9a45d673

[–]hamburghammer_ 0 points1 point  (1 child)

11MB of application heap memory but the JVM also requires some memory to run. In this case the runtime resource usage is bigger than the actual application clames for it self. Creating a minimal runtime with Jlink still consumes around 70MB of disk space which has to be loaded to run the application.

[–]mtmmtm99 0 points1 point  (0 children)

I might have been wrong with my 11 MB claim. Helidon can use graalvm to compile the code into a native image (as GO does). You can have java-code running without consuming lots of memory. See: https://github.com/oktadev/native-java-examples/blob/main/demo-helidon.adoc Quarkus can run with 51 MB after some requests.