A few years ago I personally attended a talk delivered by Tony Hoare. Amongst other things I very much enjoyed his remarks on performance. I hope I will never forget and never fail to act on his famous quote "premature optimization is the root of all evil". I have seen the horrible results of hand optimizing Go code by default and I want to avoid that my codebase looks anything like that. Today I like to get started with some performance checks of the Go codebase I have been working on. Of cause I start with some profiling...

Hi All,

I am currently working on an online course for Prometheus monitoring tools.

I always wanted to have a walldisplay in my office to visualise the Jenkins build status of my open source projects (on Jenkins I am using the "Radiator View Plugin"). So far I never implemented it because I did not like the idea of having a laptop computer running 24/7 just for that.

I have a little break between projects. So I started working to improve the visualisation tools used for performance test analysis.

Nowadays in most cases the root cause for non-performing Java applications is the suboptimal configuration for memory usage and garbage collection. The situation is even more complicated since the optimal heap configuration in most cases can neither be calculated nor guessed. The optimal configuration depends on the size of the objects and their lifespan and those depend on the (type of) application and the user behaviour. What? Did you just say that the optimal configuration depends on the user behaviour?? Yes, that's true! Basically what I want to say is that optimizing the heap configuration is not a one shot operation. You will not be able to set it right once and forget about it. You should re-evaluate your application on a regular basis and check if you have to adapt your JVM configuration to match changed circumstances. On the other hand the JVM is very forgiving and your application will perform very well with a less than optimal heap configuration.