[24] PERFORMANCE ISSUES ![UPDATED!](updated.gif)
(Part of the CORBA FAQ, Copyright © 1996)
[24.1] CAN CORBA APPLICATIONS BE TUNED FOR BETTER PERFORMANCE? ![UPDATED!](updated.gif)
[Recently added first paragraph (7/1997).
Click here to go to the next FAQ in the chain of recent changes]
Darn right. There are a number of ways to tune CORBA applications for better
performance.
- Remember that distribution should only be used if a reason to do so exists.
Distribution does not make sense for the sake of distribution. If distribution
does not serve a purpose then it should be avoided. Avoiding excessive
distribution can result in better performance. Care should be taken when
introducing distribution into an applications object model.
- IDL interfaces can be tuned to minimize network latency. Invoking remote
operations requires transmitting data across the network. Network performance
is typically optimized by ensuring adequate bandwidth. Once the required
bandwidth is achieved raw network performance cannot be increased. One key to
tuning an IDL interface is to reduce the number of network transfers that need
to occur. Calling an operation that returns 100 bytes might take 5
milliseconds. Calling an operation that returns 200 bytes of data might take
around 6 milliseconds. Calling 2 operations that return 100 bytes might take a
total of 10 milliseconds. One key to tuning IDL operations is to avoid
implementing several get operations and to combine them into a single get
operation which returns the appropriate combination of data.
- Caching results of remote operations can avoid network overhead associated
with calling the same remote methods more than once. Many applications can
perform remote operations upon startup rather than during normal usage. Users
are often more willing to wait at startup time rather than during application
usage.
- Many performance problems are associated with serialization and blocking
conditions. For example, Let us assume that clients will be making remote
operations to a single server. A single clients request causes the server to
block for a extended period of time, the entire client community might have to
wait. Make sure that multiple distributed operations are not becoming
serialized within a single server process. Utilize multiple server processes
or threaded servers instead.
[ Top | Bottom | Previous section | Next section ]
[24.2] DO DIFFERENT CORBA IMPLEMENTATIONS PERFORM AT SIGNIFICANTLY DIFFERENT LEVELS? ![UPDATED!](updated.gif)
[Recently added first paragraph (7/1997).
Click here to go to the next FAQ in the chain of recent changes]
Wow, you bet they can.
Different CORBA implementations can vary significantly in performance. Good
implementations should be fairly similar since network performance defines the
maximum achievable performance characteristics. Network latency does represent
the significant portion of distributed invocation latency.
[ Top | Bottom | Previous section | Next section ]
[24.3] WHAT TYPES OF PERFORMANCE SHOULD I BE CONCERNED WITH?
There are many different performance characteristics that are important.
Performance should also scale linearly as connections or objects increase.
While raw throughput between one client and one server is important, it is not
the only or the most critical characteristic. Many characteristics of the
CORBA implementation should be considered. As always, actual application
requirements to the relative importance of these different characteristics.
With the high speed nature of most CORBA implementations, raw client/server
throughput is often not a bottleneck. It is also important that factors such
as the number of operations does not slow down individual remote invocations.
A lists of some important performance characteristics is listed below.
- Scalability across connected client applications.
- Scalability across objects within a CORBA server.
- Raw throughout between one client and one server.
- Activation time of server processes.
- Activation time of CORBA objects.
- Streaming time for different IDL types.
- Connection time associated with the first remote operation, _narrow
call, _is_a call etc.
- Minimum memory consumed by a CORBA object.
- Number of file descriptors consumed by a complex network of distributed
objects.
[ Top | Bottom | Previous section | Next section ]
E-mail us
[ CORBA FAQ
| Table of Contents; Exhaustive; Alphabetical
| Subject index
| About the authors
| ©
| TM
| Download your own copy ]
Revised Aug 29, 1997