Скачать или смотреть #Shorts

Click here -    / @interviewdot   to get notifications.

#Shorts Put your Ktor on Kubernetes without a JVM! (and how it performs) | InterviewDOT

Kotlin is well-known for its ability to target multiple platforms through its Kotlin Multiplatform offering. In the case of Ktor applications, developers generally focus on the Java Virtual Machine (JVM), benefiting from compatibility and a vast Java ecosystem. However, the advent of native Linux compilation brings new possibilities for performance optimization by eliminating the JVM dependency.

Our test setup
To compare the performance of JVM and native Linux compilation for Ktor applications, we conducted a performance load test. We used an existing Ktor application by Simon Vergauwen targeting Linux, which we find here: https://github.com/nomisRev/ktor-k8s-.... Then we rewrote the application to target the JVM, which we find here along with all Kubernetes manifests and load test instructions.

The application manages users and has two routes:


For stress-testing the applications, we utilized ddosify, which allows us to evaluate the performance and resilience of both compilations under heavy loads. We called the GET route every second for 60 seconds. We measured image size, startup time, memory usage, CPU usage, and request duration.

Image size
The image sizes are easily accessed through the Docker CLI:

We find that the JVM application is 485.65 MB while the native Linux compilation is only 147.20 MB, which is roughly a times three reduction.

Startup time
We measured the startup time of both applications as the time difference between when the pod was started and when the container was ready. The data comes from Metrics Server. Although these metrics are measured in seconds, we could still observe a significant difference. The Linux application takes only 2 seconds, whereas the JVM needs 4 seconds.


Memory usage
Regarding memory usage, the JVM application immediately jumps to around 70 MB at startup and grows further towards 90 MB when we send requests. The Linux application, on the other hand, consistently remains between 30 and 40.

CPU usage
In terms of CPU usage, we see a similar pattern for both applications, with the Linux application being slightly better.

Request duration
Finally, the request duration (sorry for the dark mode screenshots). We observe that the Linux application arrives at a consistent request duration of around 15 milliseconds after a few requests and then stays there. The JVM application needs a bit more time to warm up but then overtakes the native compilation.

Conclusion
Compiling to a native Linux executable can be a great option when you need low memory usage, instant performance and fast startup times. Native compilation can be a viable option for serverless environments, where we are billed for memory usage and execution time.

On the other hand, JVM compilation offers compatibility with the extensive Java ecosystem, enabling seamless integration with existing Java codebases. It benefits from mature optimizations and garbage collection, making it a more attractive option for longer-running applications.

Overall, JVM compilation is a versatile choice with broad compatibility and a well-established ecosystem, making it suitable for most use cases. Native Linux compilation, on the other hand, offers enhanced performance and resource efficiency but requires careful consideration of library compatibility and may be more specialized in its use cases. Developers should evaluate their specific requirements, platform dependencies, and performance goals to make an informed decision about the compilation approach that best suits their needs.