Re: optimizing link between client and server

[dthompson characterlink net (Darrin Thompson)]

"Don't build chatty interfaces." That's good advice, I think, for any 
component or remoting system, be it CORBA, DCOM, ActiveX, COM, etc. All 
these archtectures provide incredibly good things, like network and 
language independence, but always at a small price. 

If you have to move a lot of data using CORBA, make a few big calls 
moving a lot of data instead of a lot little ones. That's sound 
optimization. 

Darrin

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 11/30/00, 10:31:01 PM, Amitabh "A." Nene <anene cup hp com> wrote 
regarding Re: optimizing link between client and server:


> Yeah, that was the kind of information I was looking for. Things like how
> much more expensive would a call within the same address space be 
compared
> to a virtual call. Is it exactly as much as a virtual call or does it do
> additional checks - will appreciate pointers to source files that
> implement call linking - at this point I am most concerned about the same
> address case since I'm thinking of using CORBA just for its interfaces so
> that I'll be scale my components to use different transports in the
> future.

> Thanks
> -Amit


> On Thu, 30 Nov 2000, Simon Britnell wrote:

> > Amitabh A. Nene wrote:
> >
> > > I wanted to know how does one go about optimizing the link between a 
CORBA
> > > client and server using ORBit / any other ORB in general. In other words,
> > > how does one configure the link depending on whether the client and 
server
> > > are in the same address space, different address spaces on the same
> > > physical machine, or on separate physical machines ?
> >
> > Hmmm.  I'm a little unsure of what you're asking.  Your question appears
> > to be "How do I select which transport an ORB is using (SHM,TCP/IP,Unix
> > Sockets,Sun RPC,etc) for any ORB?" The answer is "That depends on the
> > ORB." ORBit specifically has a configuration file /etc/orbitrc which
> > switches between unix sockets and tcp/ip as these are the transports it
> > provides.".  Many ORBs automatically make the decision to use
> > dync-call/no marshalling whenever they detect that they are both the
> > client and the server for an IOR.  I *think* ORBit is one of these.
> >
> > It also occurs to me that your real issue may be a performance one, in
> > which case I can only say "Minimise round trips".  The further the
> > distance between your client and server, the bigger the latency penalty
> > you will pay.  Calling a remote object method fetchNextFoo() repeatedly
> > to fetch a thousand records will perform fine over SHM where latency is
> > <1ms, but will die screaming over the internet even at a latency of only
> > 100ms (giving a 10 second response time for 1000 records in latency
> > alone) and >500ms latencies are not uncommon.  Far better to implement a
> > method fetchAllFoo() which is called once.
> >
> > > Also, in the current ORBit implementation, do these paths translate to
> > > dyn-call/no-marshaling, shared-mem, and RPC respectively, if at all ?
> >
> > I don't think ORBit does SHM yet.  I know it does dyn-call, unix
> > sockets, tcp/ip4 and tcp/ip6 (same ram address space, same machine,
> > seperated by network).
> >
> > Hope this helps.
> >
> >
> > _______________________________________________
> > orbit-list mailing list
> > orbit-list gnome org
> > http://mail.gnome.org/mailman/listinfo/orbit-list
> >


> _______________________________________________
> orbit-list mailing list
> orbit-list gnome org
> http://mail.gnome.org/mailman/listinfo/orbit-list