ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Ode Performance: Round I
Date Mon, 11 Jun 2007 17:41:12 GMT
Ok, I'll measure the performance improvement of single-thread versus
multiple-thread and then we see if it's worth it.

BTW, the serialization issue is already fixed (see
http://issues.apache.org/jira/browse/ODE-144).  Okay, it's a bit of a hack
but the payoff is there (2X throughput).  We can revisit the issue once the
BART work has been completed to see if the hack is still needed, or how we
can cleanly avoid the serialization.

alex

On 6/8/07, Maciej Szefler <mbs@intalio.com> wrote:
>
> BART---nifty. So to that point,I think workqueue is not worth it. As a
> temporary measure it would add complexity and confusion (certain) and
> provide negligable performance improvement (since we are not really
> addressing the key issue of avoiding serialization). To address the
> serialization bit would make it as complicated as BART.
>
> On 6/8/07, Alex Boisvert <boisvert@intalio.com> wrote:
> > I agree the proposal for BLOCKING, ASYNC, RELIABLE, TRANSACTIONAL (BART)
> is
> > a better way to go, and will make the WorkQueue idea irrelevant.    I
> was
> > looking for an incremental change that could be applied to the trunk,
> while
> > we're waiting for the BART branch to materialize and stabilize.
> >
> > Regardless, I think allowing the thread pool to be shared with the IL is
> a
> > good thing.  It means less threads in the system and better resilience
> to
> > load.  So for the ASYNC case, I hope the ILs can use the shared thread
> pool
> > whenever possible.
> >
> > alex
> >
> >
> > On 6/8/07, Maciej Szefler <mbs@intalio.com> wrote:
> > >
> > > That strikes me addressing the issue at the wrong level in the
> > > code---if we wants things to happen in one thread, then the engine
> > > should just do them in one thread, i.e. not call scheduler until it
> > > has given up on the thread. Introducing a new concept (work queue)
> > > that is shared between the engine and integration layer would be
> > > confusing... its bad enough that the IL uses the scheduler, which it
> > > really should not.
> > >
> > > -mbs
> > >
> > > On 6/8/07, Alex Boisvert <boisvert@intalio.com> wrote:
> > > > As a first step, I was thinking of allowing the composition of work
> that
> > > is
> > > > currently done in several unrelated threads into a single thread, by
> > > > introducing a WorkQueue
> > > >
> > > > Right now we have code in the engine, such as
> > > > org.apache.ode.axis2.ExternalService.invoke() -> afterCompletion()
> that
> > > uses
> > > > ExecutorService.submit(...) and I'd like to convert this into
> > > > WorkQueue.submit().
> > > >
> > > > For example, this means that org.apache.ode.axis2.OdeService would
> first
> > > > execute the transaction around odeMex.invoke() and after commit it
> would
> > > > dequeue and execute any pending items in the WorkQueue.  We would
> also
> > > need
> > > > to do the same in BpelEngineImpl.onScheduledJob() and other similar
> > > engine
> > > > entrypoints.
> > > >
> > > > The outcome of this is that we could execute all the "non-blocking"
> work
> > > > related to an external event in a single thread, if desired.
> Depending
> > > on
> > > > the WorkQueue implementation, we could have pure serial processing,
> > > parallel
> > > > processing (like now), or even a mix in-between (e.g. limiting
> > > concurrent
> > > > processing to N threads for a given instance).   This would allow
> for
> > > > optimizing response time or throughput based on the engine policy,
> or if
> > > we
> > > > want to get sophisticated, by process model.
> > > >
> > > > I think this change is relatively straightforward that it could
> happen
> > > in
> > > > the trunk without disrupting it.
> > > >
> > > > Thoughts?
> > > >
> > > > alex
> > >
> >
>

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