On Thu, Jul 24, 2008 at 10:15 PM, Raymond Auge <[EMAIL PROTECTED]> wrote: > 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.
Please do, and if so, would you be willing to share your code too? > 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. If you're willing to do such tweaks, then i'd highly recommend starting with the current head version (Velocity 1.6-dev). as has been said, there have already been a lot of performance tweaks made, and there are more in the pipeline already, just waiting on some confirmation (see VELOCITY-606 and VELOCITY-595 for those). > > On Thu, 2008-07-24 at 22:02 -0700, Nathan Bubna wrote: > >> On Thu, Jul 24, 2008 at 2:53 PM, Raymond Auge <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > ---------------------------------- > 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]
