This section presents measurements of execution times of simple invocations
on the basic RPC system and also on top of Flex.
The experiments were done on two 60MHz
Sun SPARCstation 20s running SunOS 4.1.3 and Fresco version 0.7.
The machines reside on two different 10Mbps ethernet based subnets
connected by a router.
The execution times for a single null RPC and a null invocation on a proxy
are shown in table 1.
The set up in the Sun RPC case is straightforward. A server is
started on a node and a client is started on
a different node. The client then makes null RPC calls.
The set up in the proxy case is also very similar. An object
server
is started on a node. Clients then specify which
object server they need to talk to in a semi-transparent manner and
obtain a reference to the object; this is really a
reference to the object server. The client then makes a null
invocation (an equivalent of a null RPC call) on the server.
Unlike in the Sun RPC case, the null method is invoked on the
object reference which adds a small overhead.
Table 1: Null RPC and Proxy invocation timings (in milliseconds)
Table 2: Times (in milliseconds) for operations on cached objects
Table 2 shows the timings for the various actions related to caching causally consistent objects. In this case, two clients executing on the two SPARCstations create objects and access each other's objects. Clearly, invocations on a cached object are very fast - a simple invocation on a cached object takes 20 microseconds whereas the cost of a null proxy invocation is 2.7 milliseconds. This might be expected and we now proceed to examine the overheads of caching.
The cost to create a
cacheable object is
3.8 milliseconds. This time is dominated by the time for an
inter-process communication (IPC) between the client and the
corresponding process cacher. This is required for the process cacher
to create meta-data on the object copy that the process cacher can
use while servicing requests for the object.
Validating an object copy takes 6.2 milliseconds.
Validating an object copy includes acquiring
the object's new state from a
valid copy elsewhere in the system.
For example, in the experiments conducted,
when a client accesses an invalid copy and
determines that validation is necessary,
it communicates with the consistency cacher on the node
on which the object was created.
The consistency cacher communicates
with the process cacher corresponding to the client process that
created the object (and therefore has a copy of the object) and receives
the object state. The consistency cacher then
returns the object state (and the associated
timestamps) to the requesting client.
When a valid copy is added to the cache,
cached object copies that are found to
be mutually inconsistent with the incoming copy are invalidated and
the local clock is updated.
Table 2 shows that caching an object copy takes 8 milliseconds. The actions required for caching an object copy are similar to the ones required for validation except that the client also informs the process cacher about it (one additional IPC). Once again, this is because the process cacher needs to maintain meta-data regarding the object that has been cached in order to service later requests for the object. We would like to point out that invalidations are local and take an insignificant amount of time.