Right. There are a single process and multiple threads. On Mon, Oct 27, 2008 at 10:41 AM, Drone42 <[EMAIL PROTECTED]> wrote: > > Thanks for the reply. > > Thats what I mean with collocation; if running in the same container, then > exchange should be direct and therefore very fast. > > The JBI standard says 'Note also that this processing is inherently > asynchronous; provider and consumer never share a thread. This also helps > keep components decoupled.' (page 6) > > But of cause this doesnt mean they cant share a process. I guess that then > only thread switch is needed if running in the same container. > > > > > > gnodet wrote: >> >> Not sure where you read such things about two component instances >> running in different processes. ServiceMix uses only one process and >> the JBI makes no mention of processes, I guess you misunderstood >> something here. >> Not sure also where you grab your performance figures. >> >> Performances really depends on your use case: if you put two services >> in the bus on the same ServiceMix container, inter-component >> invocation will be amazingly fast (it's just about passing an object >> from one component to the other without any serialization or such). >> If one service invokes the other one by mean of HTTP or JMS or any >> other protocol, the performances will surely drop by a big amount of >> course. >> So unless your services are deployed on two different containers, they >> should use in-VM communication, so it will be fast enough. >> >> On Fri, Oct 24, 2008 at 5:53 PM, Drone42 <[EMAIL PROTECTED]> wrote: >>> >>> I'm new to JBI and ServiceMIx, but looking into it with great interest... >>> however performance is an issue in the system I'm architecting and >>> looking >>> around the net I see that ServiceMix is fast, but not ammazingly fast. >>> >>> Typical deployments of the system I develop will contain choices on which >>> components to group together on the same node, to improve performance and >>> tradeoff with resource usage. >>> >>> Other middlewares, such as CORBA, provides performance optimizations by >>> detecting collocations (i.e. that a consumer and a provider is running in >>> the same component server / process). In this case the midleware will >>> automatically replace any remote calls with a direct call, thereby >>> removing >>> the overhead of writing to and reading from the transport. >>> >>> Why doesn't ServiceSix do the same? I see that JBI even directly mention >>> that two component instances will always run in separate processes. Why >>> force this? >>> >>> I know; I can write a wrapper of the ServiceMix API myself and handle it. >>> But I was thinking that there must be an excellent reason why this is not >>> already done... or? >>> -- >>> View this message in context: >>> http://www.nabble.com/Performance-Optimization-through-Collocation-tp20152693p20152693.html >>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> > > -- > View this message in context: > http://www.nabble.com/Performance-Optimization-through-Collocation-tp20152693p20184426.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > >
-- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
