vanderbilt university nashville, tennessee
DESCRIPTION
Institute for Software Integrated Systems. Vanderbilt University Nashville, Tennessee. Physical Assembly Mapper : A Model-driven Optimization Tool for QoS -enabled Component Middleware. RTAS 2008, April 22, 2008 Krishnakumar Balasubramanian , Douglas C. Schmidt - PowerPoint PPT PresentationTRANSCRIPT
Physical Assembly Mapper:A Model-driven Optimization Tool for QoS-enabled Component Middleware
Vanderbilt University Nashville, Tennessee
Institute for Software Integrated Systems
RTAS 2008, April 22, 2008
Krishnakumar Balasubramanian, Douglas C. Schmidt
{kitty,schmidt}@dre.vanderbilt.edu
Context: Distributed Real-time & Embedded (DRE) Systems• Stringent Quality-of-Service (QoS)
demands, e.g., real-time constraints• Simultaneous execution of multiple
applications with varying importance • Operate under limited resources
• e.g., avionics mission computing• Highly heterogeneous platform, language
& tool environments• e.g., Total Shipboard Computing
Environment (TSCE)• Use COTS middleware technologies
• CORBA, RT-Java• Use COTS Component/Service-oriented
technologies• CORBA Component Model (CCM),
EJB, Web Services
2
3
Research Challenge : System Optimization (1/2)Context
• Component middleware allows designing systems that are
• Hierarchical, i.e., individual components easily combined to form assemblies
• Reusable, i.e., each component can be used in multiple composition contexts
• Consequences of hierarchy & reusability
• Systems with large number of components
4
Research Challenge : System Optimization (2/2)Problem
• Systems with large number of components tend to exhibit
• Footprint overhead due to auxiliary middleware infrastructure in certain composition contexts
• e.g., component factories/ contexts when the components are collocated
• Latency overhead due to sub-optimal configuration of middleware
• e.g., latency between components placed in different containers
Node Application
Container
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CH
Receptacle
Facet
Event Sink
Event SourceComponent Home
Component Assembly
Component Remote Invocation
Collocated Invocation
Creates
5
Component Middleware Optimization Landscape• Middleware tries to optimize
execution for every application• Collocated method invocations
• Optimize the (de-)marshaling costs by exploiting locality
• Specialization of request path by exploiting protocol properties• Caching, Compression,
various encoding schemes• Reducing communication costs
• Moving data closer to the consumers by replication
• Reflection-based approaches• Choosing appropriate
alternate implementations at run-time
6
Related ResearchCategory Related Research
Design-time approaches
Venkita Subramonian et. al., The design and performance of configurable component middleware for DRE systems. In Proceedings of RTSS 2004.Arvind Krishna et. al., Context-Specific Middleware Specialization Techniques for Optimizing Software Product-line Architectures. In Proceedings of EuroSys 2006Frank Hunleth et. al., Footprint and Feature Management Using Aspect-oriented Programming Techniques. In Proceedings of LCTES 02, pages 38–45. ACMÖmer Erdem Demir et. al., An aspect-oriented approach to bypassing middleware layers. In Proceedings of AOSD 2007, pages 25–35, ACM.Charles Zhang et.al.,Towards just-in-time middleware architectures. In Proceedings of AOSD 2005, pages 63–74, ACM.
Runtime approaches
Ada Diaconescu et. al., Automatic performance management in component based software systems. In Proceedings of ICAC 2004, pages 214–221, IEEE.John A. Zinky et. al., Architectural Support for Quality of Service for CORBA Objects. Theory and Practice of Object Systems, 3(1):1–20, 1997.Christopher D. Gill et. al., Middleware Scheduling Optimization Techniques for DRE Systems. In Proceedings of WORDS 2002. IEEE Ronghua Zhang et. al., Controlware: A middleware architecture for feedback control of software performance. In Proceedings of ICDCS 2002,IEEE.Chenyang Lu et. al., Feedback control real-time scheduling: Framework, modeling, and algorithms. Real-Time Syst., 23(1-2):85–126, 2002.Lei Gao et. al., Application specific data replication for edge services. In Proceedings of WWW 2003, pages 449–460, ACM Press.Nirmal K. Mukhi et. al., Cooperative middleware specialization for service oriented architectures. In Proceedings of WWW 2004, pages 206–215, ACM Press.Gurdip Singh et. al., Customizing event ordering middleware for component-based systems. In Proceedings of ISORC’05, pages 359–362, IEEE
Deployment-time approaches
Sang Jeong Lee et.al., ISE01-4: Deployment time performance optimization of internet services. In Proceedings of GLOBECOM 2006. pages 1–6, IEEE.
7
Related Research: What’s missing?• Design-time approaches
• Lack high-level notation to guide optimization frameworks• Missing AST of application
• Lack application context information available only at deployment-time• Optimizations restricted to
information known at design-time
• Require inputs from designers, i.e., requires changes to applications and/or middleware
N N N N
N
N
N
N
NN
Application Abstract Syntax Tree
Related Research: What’s missing?• Runtime approaches
• Reflective approaches, dynamic reconfiguration
• Add additional overhead in the critical path
• Not suitable for all DRE systems
• Intrusive, i.e., not completely application transparent
• e.g., requires providing multiple implementations
• Deployment-time approaches• Focus on only one dimension,
e.g., performance effects of binding selection
8
9
Node Application
Container
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CH
Receptacle
Facet
Event Sink
Event SourceComponent Home
Component Assembly
Component Remote Invocation
Collocated Invocation
Creates
1.Composition overhead in large-scale systems• Blind adherence to
platform semantics• Inefficient middleware
glue code generation per component
• Examples: • Creation of a
factory object & component context per component
• Increase in overhead with increase in number of components
Component System Optimizations: Unresolved Challenges
Solution Approach: Deployment-time Fusion• New class of optimization
techniques – deployment-time fusion
• Merges multiple elements, e.g., components, QoS policies, into a semantically equivalent element
• Differences in fusion techniques
• Type of elements fused• Scope of fusion• Rules governing fusion
• e.g., Component Fusion • Merges multiple
components into a single component subject to fusion constraints
10
Deployment-Time Fusion
Component
Required Interface Provided Interface Event SinkEvent Source
Physical Assembly
Collocation Group Application AssemblyDeployment Plan
Characteristics of Deployment-time Fusion (1/2)
11
• If n = no. of candidate elements for fusion, k = no. of elements resulting from fusion, savings due to fusion will be (n – k ) / n
• Best case if k = 1, i.e., fusion creates a single element
• Given an undirected graph • G = (V,E) (fusion graph)
• V = {Candidate elements}• E = {(u,v) | u, v are elements
and CanMerge (u, v) is true}
Characteristics of Deployment-time Fusion (2/2)• If n = no. of candidate elements
for fusion, k = no. of elements resulting from fusion, savings due to fusion will be (n – k ) / n
• Best case if k = 1, i.e., fusion creates a single element
• Given an undirected graph
G = (V,E) (fusion graph)• V = {Candidate elements}• E = {(u,v) | u, v are elements
and CanMerge (u, v) is true}• Finding largest set of elements
that can be fused together = Finding maximum clique in G
• Well-known NP-Complete problem
12
Deployment-time Fusion Approach• Enumerate all maximal cliques
• NP-Hard; O(3n/3) time complexity• Our approach
• Use modified Bron-Kerbosch (BK) algorithm to enumerate maximal cliques
• Fastest known algorithm• Use domain-specific heuristics
• Stop enumeration after first maximal clique
• Remove vertices & repeat (safe due to characteristics of BK)
• Only use elements which occur equal number of times as candidates (for component fusion only)
13
Maximum Clique
Maximal Clique
Motivating Application
• US Navy Shipboard Computing System• Consists of 150 components – 10 “operational strings” with 15 components
each; deployed across 5 nodes• Sensors – Periodically sends information to the planners• System Monitors – Publish information about health of system• Planners – Process sensor & system monitor input• Effectors – Carry out planner-specified actions
14
Candidate Elements
15
Fusion Graph (Instance Level)
16
Fusion Graph (Type Level)
17
Fusion Graph (PAM)
18
Output Cliques
19
Component Fusion Algorithms (1/2)• Two variants for component
fusion• Local Component Fusion• Global Component Fusion
• Local Component Fusion• Operates at the scope of a
single deployment plan
20
Component Fusion Algorithms (1/2)• Two variants for component
fusion• Local Component Fusion• Global Component Fusion
• Local Component Fusion• Operates at the scope of a
single deployment plan• Input
• Set of components deployed into each collocation group on every node of a single deployment plan
• Output• Physical assemblies • Modified assembly &
deployment plan
21
Component Fusion Algorithms (2/2)• Global Component Fusion
• Operates at the scope of all deployment plans of a single application
• Set of components that are fused together spans multiple deployment plans
• Merges the individual deployment plans into a unified deployment plan
22
Global Component Fusion
Component
Required Interface Provided Interface Event SinkEvent Source
Physical Assembly
Collocation Group Application AssemblyDeployment Plan
Component Fusion Algorithms (2/2)• Global Component Fusion
• Operates at the scope of all deployment plans of a single application
• Set of components that are fused together spans multiple deployment plans
• Merges the individual deployment plans into a unified deployment plan
• Global vs. Local• Increased scope increases
chances of creating larger physical assemblies
23
Key Artifact of Component Fusion: Physical Assembly
24
• Physical Assembly• Created from the set of
components that are deployed within a single process of a target node
• Subject to various constraints, e.g., • No two ports of the set of
components should have the same name
• No changes to individual component implementations• Physical Assembly
indistinguishable to external clients• All valid operations on
individual components are still valid
Prototype Implementation
25
PICMLmodel
CH CH
CHCH
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
Physical Assembly Mapper
Deployment Plan
Configuration Files
CH
Required Interface
Provided Interface
Event Sink
Event SourceComponent Home
Component Assembly
Component Invocation
Creates
CH
CH
CH
CH
CH
CH
CH
CH
CH CH
CHCH
• Physical Assembly Mapper (PAM)
• Uses the application model as the input
• Exploits knowledge of platform semantics to rewrite the input model to a functionally equivalent output model
• Generates middleware glue-code
• Generates deployment configuration files
• Operates just before deployment• Can be viewed as a
“deployment-time compiler optimizer”
Applying Component Fusion to Shipboard Computing
• Creates multiple physical assemblies• Creates multiple component attributes corresponding to individual
component attributes• Maintains the same number of connections
26
Footprint Experiments Setup• Experiments were conducted
using ISISlab• Five nodes running Windows
XP SP2• CIAO Version 0.5.10 used as
baseline for comparison• Two kinds of footprint
measurements• Static – Code & Static
Data• Dynamic – Heap Memory
used • Use vadump.exe to take a
snapshot of working set of process hosting components
• Measure number of private & shareable pages
27
Footprint Results (1/2)
28
Node Specific Static Footprint
Node Specific Dynamic Footprint
Total Static Footprint Total Dynamic Footprint31% reduction
49% reduction
18% reduction
45% reduction
Footprint Results (2/2)
• Increased footprint reduction with Global vs. Local component fusion due to• More opportunities for merging components• Creation of consolidated deployment plan• Applicable to more than the internal components of an assembly• Reduces the overhead due to factory objects as well as components
29Component Fusion reduces the footprint significantly
Total Footprint18% reduction
45% reduction
Applicability of Component Fusion Techniques
30
• Opacity of object references• Components don’t rely on specific
details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• e.g., both EJB & Web Services share notion of opaque object/service references
Applicability of Component Fusion Techniques
31
• Opacity of object references• Components don’t rely on specific
details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context• Components access ports of other
components using a context object• Allows replacing context
transparent to component implementations
• e.g., EJB has a EJBContext which is very similar to CCM’s Context Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
user implemented
code
Container
CORBAComponen
t
POA
Ext
erna
lIn
terf
ace
s
InternalInterface
s
Applicability of Component Fusion Techniques
32
• Opacity of object references• Components don’t rely on specific
details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context• Components access ports of other
components using a context object• Allows replacing context
transparent to component implementations
• Clean separation between glue-code & component implementation
• Allows modifications transparent to component implementations
Techniques are broadly applicable across different middleware
Stub
Executors
Skel
IDL Compiler
IDL
CIDL
CIDL Compiler
Executor IDL
Servants
Executor Stubs
IDL Compiler
XML ComponentDescriptors
Hand-WrittenGenerated
Inherits
Concluding Remarks
33Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/
• Our research • Describes a model-driven
approach to deployment-time optimizations
• Two algorithms• Local and Global
component fusion • Implemented via the
Physical Assembly Mapper (PAM)
• PAM’s deployment-time optimization techniques
• Resulted in a 45% decrease in footprint compared to conventional middleware technologies
Thank you!
34