One big problem is that you are using Velocity.evaluate() which is not recommended for high-volume use.
If you store your templates as text files and use a ResourceLoader to retrieve as a Template object, Velocity has very efficient caching. You can store your templates as files (use FileResourceLoader), in the classpath (ClasspathResourceLoader), or in a database (DatasourceResourceLoader). The (unreleased) Velocity 1.6 (in source control trunk) contains further improvements. But you should see order of magnitude improvements from retrieving your templates with a ResourceLoader (and the caching option on) vs. Velocity.evaluate(). See the developer's manual for more details. WILL On Thu, Jul 24, 2008 at 3:46 PM, Malcolm Edgar <[EMAIL PROTECTED]> wrote: > Hi Auge, > > On the Velocity development list there is some ongoing work to address > this issue. I would recommend that you try the performance patches and > get in contact with these people. > > https://issues.apache.org/jira/browse/VELOCITY-606 > > regards Malcolm Edgar > > On Fri, Jul 25, 2008 at 7:53 AM, Raymond Auge <[EMAIL PROTECTED]> wrote: >> Hello All, >> >> My name is ray Augé. I am an engineer working for Liferay, Inc. on the >> Liferay Portlet project. >> >> We have a critical issue with Velocity performance where under large >> load Velocity becomes a bottleneck for scalability. >> >> Now, I'm fairly certain that this is perhaps because we are using >> Velocity in a way which may not leverage its scalability features. >> >> Allow me to explain the problem and our usage. >> >> Under heavy load we hit a max throughput and thread dumps during this >> time are completely filled with BLOCKED threads as bellow: >> >> [snip] >> "http-80-Processor47" daemon prio=10 tid=0x00002aabbdb90400 nid=0x5a59 >> waiting for monitor entry [0x0000000044c72000..0x0000000044c74a80] >> java.lang.Thread.State: BLOCKED (on object monitor) >> at >> org.apache.velocity.util.introspection.IntrospectorBase.getMethod(IntrospectorBase.java:103) >> - waiting to lock <0x00002aaad093d940> (a >> org.apache.velocity.util.introspection.IntrospectorCacheImpl) >> at >> org.apache.velocity.util.introspection.Introspector.getMethod(Introspector.java:101) >> at >> org.apache.velocity.util.introspection.UberspectImpl.getMethod(UberspectImpl.java:165) >> at >> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:184) >> at >> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) >> at >> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) >> at >> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) >> at org.apache.velocity.app.Velocity.evaluate(Velocity.java:322) >> at org.apache.velocity.app.Velocity.evaluate(Velocity.java:195) >> at >> com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:238) >> at >> com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:194) >> at >> org.apache.jsp.html.portal.layout.view.portlet_jsp._jspService(portlet_jsp.java:801) >> [/snip] >> >> Now here is what the Velocity usage looks like for that particular >> thread: >> >> TemplateProcessor processor = new TemplateProcessor( >> servletContext, request, response, portletId); >> >> VelocityContext vc = new VelocityContext(); >> >> vc.put("processor", processor); >> >> // Wrap a bunch of puts... >> >> VelocityVariables.insertVariables(vc, request); >> >> // many more puts here... >> vc.put(...); >> vc.put(..); >> >> StringWriter sw = new StringWriter(); >> >> try { >> Velocity.evaluate( >> vc, sw, RuntimePortletUtil.class.getName(), >> content); >> } >> catch (Exception e) { >> _log.error(e, e); >> >> throw e; >> } >> >> // eventually do >> return sw.toString(); >> >> etc.. >> >> Is there an obvious miss-use of Velocity than anyone can identify here? >> >> Wondering if we are supposed to re-use a common inner context? IF so, >> would it be a singleton? a pool of re-usable contexts? something else? >> >> Many thanks for any input, >> >> >> ---------------------------------- >> Raymond Augé >> Software Engineer >> Liferay, Inc. >> Enterprise. Open Source. For Life. >> ---------------------------------- >> >> Liferay Meetup 2008 – Los Angeles >> >> August 1, 2008 >> >> Meet and brainstorm with the creators of Liferay Portal, our partners >> and other members of our community! >> >> The day will consist of a series of technical sessions presented by our >> integration and services partners. There is time set aside for Q&A and >> corporate brainstorming to give the community a chance to give feedback >> and make suggestions! >> >> View Event Details >> >> Register Now >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
