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 Wed, 18 Jul 2007 18:55:14 GMT
Alex,

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.

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

Thanks,

Vishal

Alex Boisvert <boisvert@intalio.com> wrote: Are you using in-memory or persistent processes?
How do you determine most of the CPU time is spent in Ode?   In what parts
specifically?

On my dual-core laptop I easily get 100+ TPS with in-memory processes, so my
guess is you have a bottleneck somewhere else.   The hard part, of course,
it to find where!

alex


On 7/18/07, Vishal Bhasin  wrote:
>
> Hello All,
>
> We are performing load tests on the orchestration we have built using ODE
> (1.0) and ServiceMix (3.2-incubating).
>
> Test Case:
> Receive request from JMS Consumer, process simple business rule (using
> Drool) and make 3 external Web Services calls (using HTTP Provider) that
> returns a response very quickly (within 50 millisecs). The responses from
> the 3 Web Services is normalized in an XML using XSLT. Orchestrated XML
> response size is around 50KB
>
> Environment
> 4 CPU AMD Opteron 64-bit,  Advanced Server version 4 release 2 update 2,
> Jave 5 update 11.
>
> Results
> We are unable to go beyond 16 TPS (transactions per second), with CPU over
> 90%. We discovered that most of the time is spent within ODE SU. Obviously,
> this number is very low, is there anything that we can do to tune ODE?
>
> Thanks,
>
> Vishal
>
>
> Regards,
>
> Vishal Bhasin
>



Regards,

Vishal Bhasin

 
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message