In the previous sections, we saw how reducing the number of messages led to a proportional reduction in the time taken by the application to process those messages. Table 12-1 compares the performance between the different communications layers used in those sections.
Executing three separate methods |
Executing one combined method |
|||||
---|---|---|---|---|---|---|
Time taken |
Bytes written |
Overhead time |
Time taken |
Bytes written |
Overhead time |
|
CORBA |
512% |
291 |
194% |
175% |
106 |
66% |
RMI |
356% |
136 |
181% |
113% |
54 |
56% |
Proprietary |
293% |
40 |
80% |
100% |
20 |
31% |
Here, I detail the measurements made for the three communications layers using the tests defined in the "Message Reduction" section. The first three columns list measurements taken while executing the three updating methods together. The second three columns list the measurements taken when the single updating method updates the server object. Within each set of three columns, the first column lists the round-trip time taken for executing the methods, with all times normalized to the proprietary communications layer time in the combined method case. (The network round-trip overhead is a 10-millisecond ping time in these tests.) The second column lists the number of bytes written from the client to the server to execute one set of methods, and the third column lists the time taken to run the test with no latency (i.e., client and server on the same machine), using the same time scale as the first column.
As you can see, CORBA has more overhead than RMI, which in turn has more overhead than the proprietary system. For simple distributed applications such as those used in the examples, using a proprietary-distribution mechanism is a big win. If you include optimized serialization, which can be easily done only for the proprietary layer, the advantages would be even greater. (See Section 8.4 for examples of optimizing serialization.) However, the proprietary layer requires more work to support the distribution mechanisms, and the more complicated the application becomes, the more onerous the support is.
There is some evidence that CORBA scales significantly better than RMI as applications grow in any dimension (number of clients, number of servers, number of objects, sizes of objects, etc.). RMI was designed as a relatively simple distributed-application communications layer for Java whereas CORBA has a much more complex architecture, aimed specifically at supporting large enterprise systems. Given this difference, it is probably not surprising that CORBA has the better scaling characteristics. RMI uses significantly more resources to support certain features such as distributed garbage collection, which can impose heavy overhead at large scales. CORBA directly supports asynchronous communications at the method-definition level by allowing methods to be defined as one-way message transfers.
It appears that for simple distributed applications, a proprietary communications layer is most efficient and can be supported fairly easily. For distributed applications of moderate complexity and scale, RMI and CORBA are similar in cost, though it is easier to develop with RMI. For large-scale or very complex distributed applications, CORBA appears to win out in performance.