distributed computing implementations

[Duncan Grisby]

In article <d116fbae.0304100704.68ef4833 at posting.google.com>,
Uche Ogbuji <uche at ogbuji.net> wrote:

>True, and Mike Olson did some pretty thorough analysis on this.  See:
>
>http://www-106.ibm.com/developerworks/library/ws-pyth9/

Interesting article. Unfortunately, the first two timings of the CORBA
client aren't timing what Mike thinks they are. The first time, for
"connecting to server" doesn't actually connect to the server at all.
It just creates an object reference for it.

The second time, for "send string" _is_ timing sending a string, but
that is also when the TCP connection to the server is made. A
significant portion of the time is spent setting up the connection,
not transferring the string. If I modify the client to do the first
call twice, I get

Connecting to server
Time to connect to server, 0.000386

Sending a long string to the server
Time to send a string of 21000 chars, 0.002099

Sending a long string to the server
Time to send a string of 21000 chars, 0.001034

Recieving a long stirng from the server
Time to receive a string of 22000 chars, 0.001088

Sending lots of ints to the server
Time to send 5000 ints, 0.921309 (0.000184 per call)


So you see that the first call takes about twice as long as the second
one. Another interesting thing if you care about raw speed is that
CORBA strings are not allowed to have embedded nulls in them, and
undergo code set conversion, and checking these things slows them
down. Using a sequence of octets, which doesn't have any checks or
conversions brings the time down to 0.000827 and 0.000839 for sending
and receiving respectively.

For comparison, the raw socket client has these times on my machine:

Connecting to server
Time to connect to server, 0.001273

Sending a long string to the server
Time to send a string of 21000 chars, 0.000988

Recieving a long stirng from the server
Time to receive a string of 22000 chars, 0.000873

Sending lots of ints to the server
Time to send 5000 ints, 10.290595 (0.002058 per call)


Lies, damn lies, and statistics...

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --