Performance Analysis of CORBA

Performance Analysis of CORBA

By
S.Venkatesan
 Servant
z In CORBA,, a Servant is the invocation target,
g , containingg
methods for handling the remote method invocations.

z In the newer CORBA versions, the remote object on the

server side is split into the Object (that is exposed to remote
invocations)) and Servant ((to which the former p part delegates
g
the method calls).
 Servants and State
Servants and State
z Stateless Servants – is not associated with anyy application‐
pp
specific state in memory. This does not implies that the
CORBA object, which is implemented by the servant, is
necessarily stateless.
stateless

z Stateful Servants – is associated with some application

pp
specific state.
 Performance Implications
Performance Implications
z The number of remote method invocations that are made.

z The amount of data that is transferred with each remote

method invocation.

z The marshalling costs of the different IDL data types used by

the system
 Factors
z In LAN environment,, the number of remote method
invocations will often have the greatest impact.

z In a high‐speed network with low latency, the marshalling

costs might become more pronounced.

z The performance given for one environment is not common

for all the environments. The performance will get change
depend up on the configuration of hardware, network,
operating system, programming language, and object request
broker.
 First Version of Portfolio Manager IDL
First Version of Portfolio Manager IDL
#include <Stockwatch.idl>
interface Holding;
typedef sequence <Holding> HoldingSeq;
interface portfolio {
Money getCurrentValue();
HoldingSeq getHoldings();
};
Interface Holding
{
Unsigned long getNumberOfShares
g gg ();
Stock getStock();
};
 Access Pattern for first version
Access Pattern for first version
Portfolio Object

getHoldings()
H ldi ()
Holding Objects
getStock()
getStock()
Portfolio Portfolio Manager Server
Manger getStock()
GUI
getSymbol()
Stock Objects
Stock Objects
getSymbol()
getSymbol()

Data Broker Server
 Second Version of Access patterns
Second Version of Access patterns
//CORBA IDL
#include <StockWatch idl>
#include <StockWatch.idl>
interface Holding;
interface Portfolio
{
Money getCurrent
yg Value();
();
SymbolSeq getSymbols();
Holding getHoslingBySymbol (in Symbol aSymbol);
};

//Java
public void displaySymbols (_portfolioRdf the Portfolio)
{
SymbolSeq symbols = thePortfolio.getSymbols();
for (int idx=0; idx<symbols.length; idx++)
for (int idx 0 idx<symbols length idx++)
{
holdingList.add(holdings.buffer[idx]);
}
}
Access Pattern of version 2
Access Pattern of version 2

Portfolio Manager 
Server
getSymbols()

Portfolio Object
Portfolio Manager 
GUI
Comparing the Two Versions
Comparing the Two Versions

First Version (1 + 2 * N RMIs)

Second Version (1 RMI)

Duration
 Critical factors for Performance
Critical factors for Performance
• Number of Invocation
• Amount of data transfer
• Marshalling and unmarshalling overhead
 Breakdown of Costs
Breakdown of Costs
A significant amount of time is spent only 
A significant amount of time is spent only
TTotall cost off RMI without
ih
with marshalling/unmarshalling of object 
marshalling/unmarshalling of
references
object references.

First Version (1 + 2 * N RMIs)
 Number of Remote Invocations
Number of Remote Invocations
• Each request sent over a network connection imposes a delay,
usually referred to as “network latency”.

• This delay adds a considerable amount of time for the processing of

each CORBA remote invocation, especially in TCP/IP networks.

• The network latency imposed by each request and reply is not the
only cost factor involved in each remote invocation.

• There are other factors, like server‐side lookup, that contribute to a

constant cost factor for each remote invocation.
 Message Size
Message Size
Section Message Size Throughput
I Small Low
II Relatively large High
III Extremely High
Extremely High Low
 Message Size
Message Size
• High throughput rate can usually achieved by using few
requests each transferring a large amount of data,
requests, data
instead of many request, each transferring a small
amount of data.

• There is also problem with transferring extremely large

amountst off data
d t ini a single
i l message – if the
th message
gets too big, the throughput rate decreases again.

• Reason for this decrease in throughput include TCP

buffering issues and growing process sizes.
Marshalling Overhead for Different IDL 
Data Types
• Octet ‐ marshalling overhead is very small

• Struct – is also very simple, therefore the marshalling overhead is quite small.

• Union – Unions are slightly more complex than structs, since they can store
different types of values
values.

• String – A string is a variable length data type. The problem with variable – length
data types is that they usually involve costly memory management operations.

• Sequence – A sequence is not only a variable‐length data type, it can also store
complex IDL types.

• Any – It is more complex, since it is essentially a dynamic data type and has to
handle dynamic type codes during marshalling and unmarshalling.

• Object reference – Object references provide a powerful abstraction mechanism.

They encapsulate information such as host addresses and object identifiers, and
mappings to active network connections.
 Marshalling/Unmarshalling cost of 
d ff
different data types
d
IDL Type

Octet

struct

Union

String

Sequence

any

Object 
reference

Marshalling Cost
 IDL Drawbacks
IDL Drawbacks
• IDL data types
yp do not support
pp inheritance.
• IDL data types cannot be used describe recursive data
structures.
Recursive Class Hierarchy
Recursive Class Hierarchy
Diagram
getShapes()

*
1..*
Shape

Compound Shape Line
name:string Start: point
end : point
end : point
 IDL with error
IDL with error
struct CompoundShape {
string m_name;
sequence<Shape> m_shapes;   (1) Error!
}
Struct Line {
point m_start;
point m_end;
};
union Shape switch (short) {
case 1: Line m_Line;;
case 2 : compoundShape m_CompoundtShape;
};
 Valid One
Valid One
Struct Shape
{
Any m_details;
};
struct CompoundShape
p p {
string m_name;
sequence<Shape> m_shapes;   (1) Error!
};
Struct Line {
Line {
point m_start;
point m_end;
};
union Shape switch (short) {
case 1: Line m_Line;
case 2 : any m_CompoundShape;
};
Thank you
Thank you