ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Ode Performance: Round I
Date Wed, 06 Jun 2007 21:24:51 GMT
Howza,

I started testing a short-lived process implementing a single
request-response operation.  The process structure is as follows:

-Receive Purchase Order
-Do some assignments (schema mappings)
-Invoke CRM system to record the new PO
-Do more assignments (schema mappings)
-Invoke ERP system to record a new work order
-Send back an acknowledgment

Some deployment notes:
-All WS operations are SOAP/HTTP
-The process is deployed as "in-memory"
-The CRM and ERP systems are mocked as Axis2 services (as dumb as can be to
avoid bottlenecks)

After fixing a few minor issues (to handle the load), and fixing a few
obvious code inefficiencies which gave us roughly a 20% gain, we are now
near-100% CPU utilization.  (I'm testing on my dual-core system)   As it
stands, Ode clocks about 70 transactions per second.

Is this good?  I'd say there's room for improvement.  Based on previous work
in the field, I estimate we could get up to 300-400 transactions/second.

How do we improve this?  Well, looking at the end-to-end execution of the
process, I counted 4 thread-switches and 4 JTA transactions.  Those are not
really necessary, if you ask me.  I think significant improvements could be
made if we could run this process straight-through, meaning in a single
thread and a single transaction.  (Not to mention it would make things
easier to monitor and measure ;)

Also, to give you an idea, the top 3 areas where we spend most of our CPU
today are:

1) Serialization/deserialization of the Jacob state (I'm evaluating about
40-50%)
2) XML marshaling/unmarshaling (About 10-20%)
3) XML processing:  XPath evaluation + assignments (About 10-20%)

(The rest would be about 20%; I need to load up JProbe or DTrace to provide
more accurate measurements.  My current estimates are a mix of
non-scientific statistical sampling of thread dumps and a quick run with the
JVM's built-in profiler)

So my general question is...  how do we get started on the single thread +
single transaction refactoring?    Anybody already gave some thoughts to
this?  Are there any pending design issues before we start?  How do we work
on this without disrupting other parts of the system?  Do we start a new
branch?

alex

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