velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <ra...@liferay.com>
Subject Re: Velocity Performance and Concurrency issues
Date Fri, 25 Jul 2008 05:15:59 GMT
Hello Nathan,

I just finished writing a alternate UberspectImpl based on our own
MethodCache implementation. I'll let you know if we notice any
significant changes in performance.

Ray

PS: We had already done some tweaking to use ConcurrentHashMap and
removed some sync blocks in the cache... but we still hit a bottleneck.


On Thu, 2008-07-24 at 22:02 -0700, Nathan Bubna wrote:

> On Thu, Jul 24, 2008 at 2:53 PM, Raymond Auge <rauge@liferay.com> wrote:
> #snip()
> > 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)
> #snip()
> 
> I do find it interesting that there is so much blocking going on at
> this particular point.  I didn't appearing all that high on any of the
> profiler outputs yet.  Perhaps that's just oversight on my part or
> perhaps that may be because of the heavy evaluate() use in this
> particular case, but still, if we can find a way to speed it up, that
> would be good nonetheless.   I'll look into it a bit.  It may turn out
> to be another spot that mostly needs to wait for the JDK 1.5
> concurrency classes, but perhaps there is something that can be done.
>  I do notice right off the bat that the synchronization of the get()
> and put() methods of IntrospectorCacheImpl seems unnecessary as they
> are being used within a block synchronized on their instance.  With
> re-entrant synchronization that might not make a big difference, but
> it's something.  I bet we could also be more fine-grained here and
> synchronize on something like the Class being introspected.
> 
> ---------------------------------------------------------------------
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message