velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Todd.McClint...@wellsfargo.com>
Subject RE: Velocity Performance and Concurrency issues
Date Fri, 25 Jul 2008 00:16:46 GMT
Will,

I've been following this chain because we are implementing velocity in a high volume environment.

I've seen the property to turn FileResourceLoader caching on and off.

I haven't seen a property that turns ClasspathResourceLoader caching on and off.  Does ClasspathResourceLoader
support template caching?  If it does which properties are used to configure it?

Thanks

Todd McClintock

-----Original Message-----
From: Will Glass-Husain [mailto:wglasshusain@gmail.com] 
Sent: Thursday, July 24, 2008 4:39 PM
To: Velocity Users List
Cc: rauge@liferay.com
Subject: Re: Velocity Performance and Concurrency issues

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 <malcolm.edgar@gmail.com> 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 <rauge@liferay.com> 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(portle
>> t_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: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>



--
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org


Mime
View raw message