Performance of DCE RPC

A. M. Khandker
[email protected]

P. Honeyman
[email protected]

T. J. Teorey
[email protected]

1 Introduction

The Open Software Foundation's Distributed Computing Environment (OSF/DCE) platform for distributed computing has the goal of facilitating application level interoperability in a heterogeneous environment [4]. DCE is a collection of tools and services for the development, use, and maintenance of transparent distributed systems using the client/server architecture. The communication paradigm supported by DCE is the synchronous remote procedure call (RPC). DCE also supports multithreading within an address space for concurrency. To the programmer, RPC is similar to a procedure call in a sequential program, therefore no major paradigm shift is required on the part of the programmer, unless threads are employed for better concurrency.

Like any real-world computer system, the performance of DCE is crucial to its success. In measuring performance, we focus first on the latency and throughput of RPC, which is fundamental to the overall performance of DCE. Round trip time, also known as the latency, or response time, includes the overhead associated with the RPC layer, as well as delays at the transport and network layer. We also report on the effect of using application level DCE threads for improving the throughput.

Second, we measure the average completion time of various steps of single inter-machine RPCs. The figures tell us how much time is spent in each of these steps and allow us to estimate how much faster the RPC would be if certain improvements were made, enabling us to isolate the most beneficial optimizations.

We also investigate how the completion time of various steps contribute to the the round trip time. Often, the steps at the client and the server are performed concurrently or overlap with network transmission time. Hence, not all RPC steps performed by the client, server, or the network contribute to the round trip time of the RPC. We show the steps in our environment, that do contribute to the round trip time for RPCs with various data sizes. The close match between the sum of the completion times of these steps and the measured round trip time verifies the results presented in this paper.

The round trip time that we found by summingup the completion time of steps on round trip path does not take queueing delays into account, but our results can be fed into a more elaborate model that does account for queueing delays. The measurement work described in this paper provides groundwork for a larger goal of developing more elaborate performance models.

2 Related Work

Schroeder's detailed measurement of the elapsed time at various steps of Firefly RPC serves as a model and inspiration for our work [6]. Other related performance work includes the performance