velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <wglasshus...@gmail.com>
Subject Re: Velocity Performance and Concurrency issues
Date Fri, 25 Jul 2008 04:23:53 GMT
I've never seen that pattern, but it seems reasonable.  If you test it
and it makes a difference, let us know.

Caching the templates is the main thing though.  And a comment to
Todd-- caching works for any of the resource loaders, even if you
build a custom one yourself.

WILL

On Thu, Jul 24, 2008 at 6:06 PM, Raymond Auge <rauge@liferay.com> wrote:
> Ok, before moving on those ideas, we've made a small change to the
> following:
>
>
> 		VelocityContext velocityContext = null;
>
> 		// LEP-6865
>
> 		if (_innerVelocityContext == null) {
> 			velocityContext = new VelocityContext();
>
> 			_innerVelocityContext = velocityContext;
> 		}
> 		else {
> 			velocityContext = new VelocityContext(_innerVelocityContext);
> 		}
>
> 		velocityContext.put("processor", processor);
>
> 		// Velocity variables
>
> 		VelocityVariables.insertVariables(velocityContext, request);
>
>
> Where "_innerVelocityContext" is a static instance.
>
> Does this seem like a logical move?
>
>
>
> My next questions is... IF the many "puts" made by
>
> VelocityVariables.insertVariables
>
> are actually utility classes and not runtime values, should these be added
> to the "_innerVelocityContext" so that their introspection meta-data is
> cached for subsequent use?
>
> OR does this increase the likelihood of encountering concurrency issues?
>
>
> Thanks,
>
> Ray
>
> On Thu, 2008-07-24 at 20:30 -0400, Raymond Auge wrote:
>
> Thanks Will, Malcolm, All,
>
> I'll take in these ideas and see how we can work them into a solution.
>
> Ray
>
> On Thu, 2008-07-24 at 16:39 -0700, Will Glass-Husain wrote:
>
> 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(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: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
>
>
> ----------------------------------
> 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
>
> ----------------------------------
> 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



-- 
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


Mime
View raw message