Blogs

So I finally got around to making the Velocity improvements I'd had planned on doing for the last several months. We completely removed the Velocity singleton usage and replaced it with the VelocityEngine instance design. With this, Liferay is able to play nicely with other velocity apps in the same JVM. Also, because we centralized the usage, we were able to optimize tool loading so that we don't waste resources repopulating those all the time. This also allowed us to pre-configure different tool configurations to control accessibly for the purpose of security. i.e. different tools from Themes than from Web Content Templates.

Since much of our Velocity use originates as VTL in String form, we put in place Velocity's new StringResourceLoader so that we could make sure to obtain and cache the resulting Template objects by name, such that we can gain from not having our Strings re-parsed on each evaluation.

For instance, each layout template is provided to the Velocity engine as a VTL String which is evaluated into a Template object and then merged with the parameters put into the velocity context. The optimization comes from first providing a name which uniquely idientifes the VTL String, which results in a Template object that gets cached and which we can later call by name. As such, we don't have to pay the cost of re-evaluating the VTL String each time as before. If you get 100 requests per minute, it means 100 evaluations of the VTL String to Template and then 100 merges of Template and context parameters. And yet the VTL String does not change so often, so retaining the resulting Template is optimal, as that is the most costly step in the process.

Considering how many VTL Strings the portal is handling on a given request: theme templates, layout templates, journal templates, you can see how this can begin to pile up. A cached Template object can be used over and over, with very little cost for the merge phase. This might seem like it means higher memory consumption due to the fact that we're hanging onto these Template objects, but in fact this is not the case, since the Template objects can be used for many requests and for as long as we're willing to keep them around. We're actually drastically reducing object creation and subsequent collection.

Hopefully the new design will prove to be a significant performance improvement and pay off in the form of a more responsive user experience, higher overall throughput, and finally greater concurrent load due to more efficient resource utilization.

Note: This change was committed to trunk today, and was backported to the 5.1.x branch earlier this evening.

Enjoy!