[seam-dev] InitialContext performance issues

[Jay Balunas]

oh - I'm not saying this is the biggest part of the IntialContext blocks.
The largest by far is all the calls to "lookup".  This was just the first
one that I pinned down, and seemed like an easy fix.  I'm looking at the
lookup calls, and will post more on it.

FYI - When I profiled with the patch I included the block simply moved
farther down into the InitialContext creation code.  So a real fix would be
limiting the number of instantiations, but as you say it might not be worth
the effort.  We'll have to see once we have optimized else where.

-Jay

On Tue, Sep 30, 2008 at 4:37 PM, Gavin King <gavin at hibernate.org> wrote:

> Good work, Jay. I'm surprised to find that this is an issue. Really,
> creation of
> an InitialContext should be very lightweight (it should be optimized by the
> appserver). But if it's not, then Seam should optimize it.
>
> On Tue, Sep 30, 2008 at 2:01 PM, Jay Balunas <tech4j at gmail.com> wrote:
> > I have been looking more into the InitialContext and some of the
> performance
> > issues surrounding it.
> >
> > There are really a couple of things to look at.  One is how the
> > InitialContext is created, and manged, and the other broad category is
> how
> > often and what items are looked up?  I have investigated the first, and
> have
> > begun investigating the second.
> >
> > InitialContext creation and management
> > ------------------------------------------------
> > The only location were seam creates and manages the InitialContext is the
> > "org.jboss.seam.util.Naming" class (see:
> >
> http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/Naming.java?r=5444
> > ).
> >
> > The properties are set in one location and done only once in the
> > initialization of seam (see:
> >
> http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/Initialization.java?r=9116#l915
> > ).
> >
> > I see two issues here - one is creating the initial context every single
> > time it is needed, and the other is processing/checking the properties
> every
> > time it is called.
> >
> > The first issue would require some caching mechanism or logic for reuse.
>  I
> > am not an expert on when it makes sense to reuse an instance of the
> > InitialContext, and when we need to get it fresh.  I can say that we
> > currently use they exact same properties to initialize it and those are
> set
> > during Seam initialization and do not appear to ever change once created.
> > Is there a way to cache and optimize this instantiation?
> >
> > The second issue is that we do a certain amount of processing every time
> the
> > context is requested, this could be optimized.  Currently I see a few
> > blocked threads on the "props.size()" call in the Naming class which is a
> > synchronized method on the Hashtable.  This could easily be avoided.
> > Although we need to maintain the logic that if the property list is empty
> we
> > continue to call "new InitialContext()" and not pass in the properties
> > object.  This is because the first thing the InitialContext constructor
> does
> > with a properties object is clone it which can be costly.  I have
> attached a
> > patch that implements these changes for review.
> >
> > Another item I noticed is that the only place (excluding some test code)
> > that does not use "Naming.getInitialContext()" is the
> > "org.jboss.seam.remoting.messaging.JBossConnectionProvider".  It using
> the
> > "new InitialContext()" directly.  Shane - is there a reason for this?
> >
> > I'll write up my findings on the lookup usage asap.
> >
> > Thanks,
> > Jay
> > --
> > blog: http://in.relation.to/Bloggers/Jay
> >
> > _______________________________________________
> > seam-dev mailing list
> > seam-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/seam-dev
> >
> >
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20080930/2801689c/attachment.html