[jira] Updated: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Smith updated VELOCITY-223: Attachment: AllVelocityMemoryByClass.html Attaching HTML page (no pics sorry) that shows the number of objects and their owned object size using YourKit's memory profiler. > VMs that use a large number of directives and macros use excessive amounts of > memory - over 4-6MB RAM per form > -- > > Key: VELOCITY-223 > URL: https://issues.apache.org/jira/browse/VELOCITY-223 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.3.1 > Environment: Operating System: All > Platform: All >Reporter: Christian Nichols > Fix For: 1.6 > > Attachments: AllVelocityMemoryByClass.html, VelocityMemory.JPG > > > Our application FinanceCenter is based on Velocity as the template engine. > We > have a library of about 200 macros and about 400 VM files. Because the > velocity parser copies the macro body into the VM during parsing, macros that > are frequently used (even though identical and using local contexts) use up > large amounts of memory. On our Linux server (running Redhat 7.2 with Sun > JDK > 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many > forms > (about 150) - the server starts out using 60MB after startup. This memory > times out after 5 minutes and is returned which tells me that it is screen > memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently > limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair > number > of forms in the application leaves little space for user session data. > We have implemented a caching mechanism for compiled templates and integrated > it into Velocity so that cached objects are timed out of the cache but the > server is still using large amounts of memory. We finally had to rewrite > many > of our macros into Java so that memory usage would be reduced (note that > these > macros were doing complex screen formatting not business logic). Doing this > has reduced our memory by about 30%. This is currently our biggest issue > with > Velocity and is causing us to review our decision to stay with Velocity going > forward. This is because we will likely end up with close to 1,000 forms by > the end of next year and need to know that Velocity can deal with this. Is > there any work underway to share compiled macro AST's? This would greatly > reduce the amount of memory used. I have reviewed the parser code that is > doing this but it seems that this is an embedded part of the design and not > easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475913 ] Ryan Smith commented on VELOCITY-223: - 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. 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.vm14,369,000 774 po/details.vm11,140,9528,368 sub.vm 10,115,096 24,576 > VMs that use a large number of directives and macros use excessive amounts of > memory - over 4-6MB RAM per form > -- > > Key: VELOCITY-223 > URL: https://issues.apache.org/jira/browse/VELOCITY-223 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.3.1 > Environment: Operating System: All > Platform: All >Reporter: Christian Nichols > Fix For: 1.6 > > Attachments: VelocityMemory.JPG > > > Our application FinanceCenter is based on Velocity as the template engine. > We > have a library of about 200 macros and about 400 VM files. Because the > velocity parser copies the macro body into the VM during parsing, macros that > are frequently used (even though identical and using local contexts) use up > large amounts of memory. On our Linux server (running Redhat 7.2 with Sun > JDK > 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many > forms > (about 150) - the server starts out using 60MB after startup. This memory > times out after 5 minutes and is returned which tells me that it is screen > memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently > limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair > number > of forms in the application leaves little space for user session data. > We have implemented a caching mechanism for compiled templates and integrated > it into Velocity so that cached objects are timed out of the cache but the > server is still using large amounts of memory. We finally had to rewrite > many > of our macros into Java so that memory usage would be reduced (note that > these > macros were doing complex screen formatting not business logic). Doing this > has reduced our memory by about 30%. This is currently our biggest issue > with > Velocity and is causing us to review our decision to stay with Velocity going > forward. This is because we will likely end up with close to 1,000 forms by > the end of next year and need to know that Velocity can deal with this. Is > there any work underway to share compiled macro AST's? This would greatly > reduce the amount of memory used. I have reviewed the parser code that is > doing this but it seems that this is an embedded part of the design and not > easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Smith updated VELOCITY-223: Attachment: VelocityMemory.JPG This is a picture of the YourKit memory for all of the owned objects for one of our library files. > VMs that use a large number of directives and macros use excessive amounts of > memory - over 4-6MB RAM per form > -- > > Key: VELOCITY-223 > URL: https://issues.apache.org/jira/browse/VELOCITY-223 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.3.1 > Environment: Operating System: All > Platform: All >Reporter: Christian Nichols > Fix For: 1.6 > > Attachments: VelocityMemory.JPG > > > Our application FinanceCenter is based on Velocity as the template engine. > We > have a library of about 200 macros and about 400 VM files. Because the > velocity parser copies the macro body into the VM during parsing, macros that > are frequently used (even though identical and using local contexts) use up > large amounts of memory. On our Linux server (running Redhat 7.2 with Sun > JDK > 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many > forms > (about 150) - the server starts out using 60MB after startup. This memory > times out after 5 minutes and is returned which tells me that it is screen > memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently > limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair > number > of forms in the application leaves little space for user session data. > We have implemented a caching mechanism for compiled templates and integrated > it into Velocity so that cached objects are timed out of the cache but the > server is still using large amounts of memory. We finally had to rewrite > many > of our macros into Java so that memory usage would be reduced (note that > these > macros were doing complex screen formatting not business logic). Doing this > has reduced our memory by about 30%. This is currently our biggest issue > with > Velocity and is causing us to review our decision to stay with Velocity going > forward. This is because we will likely end up with close to 1,000 forms by > the end of next year and need to know that Velocity can deal with this. Is > there any work underway to share compiled macro AST's? This would greatly > reduce the amount of memory used. I have reviewed the parser code that is > doing this but it seems that this is an embedded part of the design and not > easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]