Comparing Logging in Docker - GraalVM vs JVM
How does your machine resource usage vary if you log to console vs log to file? What about if you're using GraalVM instead of the normal JVM? Know your tools.
Why would you want to do this?
It used to be that you could get a lot of bang for your buck in terms of performance by making your logging solution better. People in the low latency/high throughput space have historically rolled their own logging solution, even if it's just simply writing to memory mapped files. Before Log4j 2 integrated the Ringbuffer, making the logging based on a circular buffer was a trick I had also used. Microservices make things a lot more complicated in terms of having a logging system that is responsive and handles correlation Ids, but for this discussion I am leaving things like Graylog and ELK to the side for now.
As workloads and demand vary, one thing remains the same - businesses strive for cost effectiveness via a reduced footprint. So whilst logging latency or throughput may not be your primary concern for UX, it probably does have an impact on your costs and bottom line.
Either way, I wanted to know how much difference there was in CPU and memory usage when logging to console vs. to file and also how that differed between using the regular JVM and GraalVM, both on Docker, so off I went.
What did you find out?
No big differences in CPU usage really, but the memory usage was a bit more interesting. Though perhaps complicated by how memory usage is reported (and me not adding any GC logging), the console based logging used up more memory than logging to a file.
- Logging to console using the JVM is the worst
- Logging to file using GraalVM is the best
- You get a bigger %age reduction in memory usage by file logging vs. console logging when it comes to GraalVM
- The %age reduction in memory usage by file logging vs. console logging when using the regular JVM is still appreciable
Show me some graphs?
You got it:
