Thanks Alex, we'll try these suggestions and report back!

Alex Boisvert <[EMAIL PROTECTED]> wrote: On 7/18/07, Vishal Bhasin <[EMAIL 
PROTECTED]> 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.

cheers,
alex

 


Regards,

Vishal Bhasin

       
---------------------------------
Pinpoint customers who are looking for what you sell. 

Reply via email to