How we boosted Magnolia response times with the dynamic page caching

We started with a quick check using the Google developer tools, just to get a feeling were the time is lost. As time was lost equally on server and browser, we decided to check the server-side first. The server-side was running the Magnolia CMS on top of the Tomcat server, so nothing special actually. We chose inspectIT (open-source APM tool for java) for the performance diagnosis and adapted the Tomcat start script to start with the inspectIT agent.

Out of the box we were able to get the basic information about HTTP request timings – with one user accessing the start page average response was approximately 1.6 seconds. Knowing that Magnolia was used as the CMS we instrumented application services and Magnolia filters and rendering engine classes. This was done in oder to get more information on where exactly was the time lost – the Magnolia or the application services.

As inspectIT provides detailed trace information for every request, we got the information we were looking for. Here is a screenshot from the tool showing one request execution path:

As you can see 99.9% of the HTTP request time (1.617s out of 1.624s) was spent in the Magnolia’s DefaultRenderingEngine.render() method. This method seams to be recursive and it’s rendering one-by-one all the elements that will be displayed on the HTML page. In addition, the reported CPU time of the method is approximately the same, meaning that the method is fully utilizing the CPU. This was an obvious problem, because the CPU will become the bottleneck as soon as more than one user is accessing the page. Furthermore, we concluded that the start page displayed to the user is always the same and has no dynamic content whatsoever, but on the other hand rendering is happening with every request. So we wandered if the caching can help us here.

Luckily enough, Magnolia introduced the Dynamic Page Caching module from the version 5.4. The operations installed the module quickly and we were able to test again. The inspectIT proved that the caching was doing its job – the requests were executed in a few milliseconds. How cool is that:

For the end have a look on the comparison in the Google Developer Tools Timeline for that first HTML request. Dynamic caching gave us a great performance boost and better experiences for the user. Thus, take the inspectIT or any similar tool, get a better insight into your application and try to improve performance today.

Google Developer Tools Timeline without dynamic caching

Google Developer Tools Timeline with dynamic caching