ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vishal Bhasin <vbha...@yahoo.com>
Subject Re: Load Testing
Date Thu, 19 Jul 2007 00:26:39 GMT
Thanks Alex, we'll try these suggestions and report back!

Alex Boisvert <boisvert@intalio.com> wrote: On 7/18/07, Vishal Bhasin <vbhasin@yahoo.com>
wrote: We are using in-memory. I see most latency in ODE service..I don't have a way to determine
CPU utilization by service unit.

I added instrumentation in the code to find time spent in each service unit..time spent in
all but ODE -SU is less than 40 ms..but ODE-SU is around 2000 ms. 
You might want to try with and without your XSL transform.  This is something I have not benchmarked
yet.  Otherwise, the code paths should be relatively the same.

 What test case did you run on your laptop? Also, do you have any optimization tips?

I ran the scenario illustrated in the attachment.  Everything SOAP/HTTP.

Things to consider:
1) If using -trunk, use JAVA_OPTS with "- Dorg.apache.ode.jbi.sendSynch=true"
     I get better performance with this setting; and there seems to be an Ode memory leak
related to async processing in JBI.

2) You might want to experiment with "- Dorg.apache.ode.jbi.msgmap.repair=false"
    This avoids some XML re-parsing.  It was introduced some time ago because we had a couple
StAX to DOM conversion issues but they might no longer apply.

3) As a rule of thumb, I usually recommend starting with 20 threads/CPU (overall).  This is
generally enough to saturate CPU under reasonable network and disk I/O.  A smaller number
of threads is usually faster if your I/Os are short but you might need more if you have long
HTTP requests, for example.  If your CPUs are already 90%+ busy, then you have enough threads.
4) For tracking down bottlenecks, I personally like taking thread-dump samples.  It's sort
of a statistical approach to performance monitoring.  By looking at the stack traces, you'll
see what the code is up to and you can figure out if there are unexpected things happening,
such as the CPU spending disproportionate amounts of time in some area of the code.   I use
the standard "jstack" and "jconsole" utilities from the JDK for this, although you can also
use CTRL-BREAK (Windows) or CTRL-\ (Unix) directly in the console. 

That's about all I can think of now...  I believe in-memory processes should perform well
out-of-the-box so I'm curious to hear what's different in your scenario.




Vishal Bhasin

Pinpoint customers who are looking for what you sell. 
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message