230 likes | 342 Views
Model Driven Performance Analysis. University College London James Skene – j.skene@cs.ucl.ac.uk. Outline. Requirements for the analysis method, as I see them. Overview of the model driven performance approach chosen Rationale related to the requirements. Future work.
E N D
Model Driven Performance Analysis University College London James Skene – j.skene@cs.ucl.ac.uk
Outline • Requirements for the analysis method, as I see them. • Overview of the model driven performance approach chosen • Rationale related to the requirements. • Future work
Performance Analysis Functional Requirements • Assuming the existence of the TAPAS platform… • Reason about compositionality of service level agreements • Predict application capacity • Over-provisioning or under provisioning w.r.t SLAs a cost. • Targeted at ASP technologies • Enable design time performance prediction • Select architecture
Non-functional requirements • Be usable: • Performance analysis outside usual software engineering competence • Must be integrated with standard software engineering practice • Minimise cost of performance analysis. • Be used: • Performance analysis is currently not performed despite benefits
Approach • Mappings from analysis to design models within the Model Driven Architecture (MDA) • Qualitatively: • Includes UML so is integrated with standard software engineering practice. • Is tool supported, so: • Can integrate the technique • Can provide assistance with the technique • Can automate the technique • Also meets the functional requirements!
The Model Driven Architecture (MDA) • Family of specifications • UML – The Unified Modelling Language • MOF – The Meta-Object Facility • CWM – The Common Warehouse Meta-model • Also: CORBA – The Common Object-Request Broker Architecture • Not really an architecture • Software designs captured as UML models
PIMs and PSMs • Problem: Technical infrastructure changes independently of business rules, but these are strongly coupled in designs. • Solution: Decouple them Platform Independent Model (PIM) Platform Specific Model (PSM) «realize»
Semantic domains • PIMs and PSMs relate to different types of thing. • It is convenient to describe these designs using different languages. • E.g. EJB implementation details • UML can describe object oriented designs. • UML contains extension mechanisms to provide additional interpretations for model elements.
Virtual Metamodel Profile Metamodels UML Meta-model: Model: PIM PSM
Profiles • The lightweight extension mechanisms: • Stereotypes extend the meaning of UML model elements. • Tagged values associate qualities with model elements. • Constraints govern the form of models, enforcing domain semantics. Act at meta-model level. • Profiles group stereotypes, tagged values and constraints. • Freedom through constraint • Opportunity for standardisation
PIM Analysis Results PSM Source Code Mappings PIM PSM
How are mappings described? • Imperative mappings specify an algorithm • Declarative mappings specify pair-wise constraints • Declarative mappings can be captured in a profile using constraints. «profile» Design «profile» QN «profile» Mapping
Benefits of mappings • They can be checked, providing assistance to modellers • Declarative mappings only need to be partially specified • The flexibility addresses the difficulty in producing feasible analysis models. • The mappings define a semantics for the design domain, in terms of the analysis domain concepts. • The declarative mappings provide guidance for subsequent automated mappings. • Can capture expert modelling techniques
Design domain: A soft-real-time profile Based on the ‘UML Profile for Schedulability, Performance, and Time Specification’ • Stereotypes to: • Identify workload classes • Identify resources accessed under mutual exclusion • Identify actions having resource demands
A Soft-real-time profile 2 • Tagged values to: • Specify workload parameters (e.g. population, think-time, or arrival rate) • Specify resource demands for actions/procedures • Specify probabilities for choices, average number of iterations. • Constraints: • Object containing action with resource demand must be deployed in context where resource is available.
{repetitions = 100, demand={cpu:10000}} {p= 0.5, demand={cpu:100, disk1:5}} {demand={cpu:100, disk1:5}} Example design model - sequence :UpdateBean :ManagerBean :EmployeeBean 1:update() 2:ejbCreate() 3:ejbCreate()
{serviceRate=0.1s} {serviceRate=0.1s} {serviceRate=0.001s} Example design model – deployment Platform «resource» CPU «deploys» :UpdateBean «resource» Disk1 :ManagerBean «deploys» :EmployeeBean «resource» Disk2 «deploys»
A performance analysis domain profile • Queuing networks • Stereotypes: • Identify instances as queues, delays or populations. • Tagged values: • Specify service intervals and probabilities on links. • Constraints: • Ensure that the network is connected.
{thinkTime = 5sec, Population = 15} {serviceRate = 1000} {p = 0.05} {p = 0.05} {p = 0.02} {serviceRate = 0.1} {serviceRate = 0.1} Example QN Collaboration «queue» Disk1 «client» Workload «queue» CPU «queue» Disk2
Mapping from design to analysis domain • Resources correspond to queues. • Resource demands translate to probabilities or demand vectors. • Much more complicated mappings will be required to capture infrastructure details (e.g. performance of containers). «model» Design «model» QN «DesignToQN»
Tool: Analysis Lifecycle QN SLAng SPA SPN EJB MQ server Oracle Requirements? PIM PSM
Progress • SLAng identifies relevant scenarios and technologies. • Assembling a toolset: • Poseidon UML • MDR plug-in for NetBeans • LUI OCL checker, NEPTUNE project • Libraries and tools for performance analysis
Future work • Define profiles • Associate with SLAng constructs • Create tool to automate analysis • Integrate into single IDE • Automate mappings