We have a web site where we use velocity to generate our HTML pages.
Recently I was asked to help troubleshoot some performance issues and
the root cause of our problem was that the velocity cache had grown to
well over 1GB in size causing the JVM to continuously GC to try to free
up memory.

As a short term fix I have grabbed the 1.5 beta ResourceCacheImpl class
so that a maximum cache size can be set and enforced.  Unfortunately
when this was done the performance of the site degraded significantly as
the pages were continuously compiled.

I used the YourKit memory profiler and found the following information
about the individual velocity cache entries (see attached picture):

Name                     Cache Size      File Size
---------------------------------------------------
VM_framework_library.vm   9,596,472      130,500
VM_buttons_library.vm     1,195,680       39,113
VM_layout_library.vm      1,683,256       54,371
admin/AdminHome.vm       32,505,168          979
poNewGrid.vm             14,399,648          753
poTemplateGrid.vm        14,369,000          774
po/details.vm            11,140,952        8,368
sub.vm                   10,115,096       24,576


At this time we have made a very heavy investment in velocity as our
presentation layer framework and love it.  In order to meet our
performance goals, we need to keep as many of the velocity pages in
cache as we can but if we do that, we can only fit 2 web applications
per Tomcat deployment in a 32 bit environment.

In searching through the JIRA issues, I found (
http://issues.apache.org/jira/browse/VELOCITY-450 ) and (
http://issues.apache.org/jira/browse/VELOCITY-223 ) that reference this
exact issue as well as the wiki entry talking about how to reduce the
memory footprint.

I am sending email to the developers list offering up my time to assist
with this issue.  I was hoping that there would be someone who would be
able to point me in a direction to get me started and that there would
potentially be some "big wins" that we could take advantage of.

Are there any places where velocity is hanging on to strings, tokens, or
processing instructions where we could potentially free them up?  Are
there other ways of factoring macros, files, or #parses that will help
in reducing the footprint?  Is there potentially extra data in any of
the AST classes that isn't necessary after parsing or is potentially
duplicate?

Thank you, 

Ryan Smith

 <<VelocityMemory.JPG>> 
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to