Message posted by Douglas C. Schmidt in comp.soft-sys.ace on August 29, 1998.
Various people have asked us what the cost is of being
compliant with the standard CORBA GIOP/IIOP protocol. Tonight, we
found out... Carlos modified TAO so that we can optionally use a
"stripped down" IIOP protocol, i.e., "-ORBiioplite". I've enclosed
some preliminary results and our interpretation.
----------------------------------------
Using the standard IDL_Cubit benchmark using standard IIOP, we see the
following sizes in bytes for the GIOP header and the request header +
the data:
GIOP header = 12 bytes
Request header + data = 56 bytes
Our "IIOP lite" optimization omits the GIOP magic number, the IIOP
version number, the byte-order flag, the service context, and the
principal. These optimizations save 14 bytes, yielding the following
size:
GIOP header = 5 bytes
Request header + data = 49 bytes
We could reduce the size of the request header even further by adding
features like active demultiplexing for POAs, servants, and
operations. Likewise, we could assume that all requests were twoways.
Of course, this quickly becomes counter-productive since we'd no
longer be performing operation-based distributed object computing
(i.e., we could just pass a message without any operation name, but
this is a pretty lame programming model... ;-)).
----------------------------------------
So, in general, our performance measurements indicated that these IIOP
lite optimizations yield about 50 calls per second improvement, in the
best case. However, this is only a ~2% improvement in performance
since we're getting around 2,000 calls per second.
In contrast, our new Service Configurator option "-ORBreactorlock
null" (which uses the null-lock Select_Reactor that Nanbor recently
added) gives us a performance boost of ~100 calls per second, showing
once again that implementation details are the key to performance,
rather than the standard CORBA protocols, per se.
Therefore, we don't see much of a penalty for remaining standard
GIOP/IIOP compliant, though we intend to support our IIOP lite
optimizations in TAO for our sponsors who want to squeeze every last
microsecond of performance overhead out of the ORB.