Including CORBA performance details into MDA System models

Transcription

1 Including CORBA performance details into MDA System models Tom Verdickt, Bart Dhoedt, Frank Gielen, Piet Demeester UNIVERSITEIT GENT 1

2 Overview Software Performance Engineering SPE + MDA Middleware Transformation Conclusion 2

3 Traditional software design Performance requirements Functional requirements design Architecture coding Working program simulation Performance parameters fine-tuning Finished program 3

4 Problem Traditional software design: functionality Performance only checked in finished product Result: - changes and fine-tuning in final stages expensive (over budget) time-consuming (missed deadlines) - poor performance in final system (bad software) Software quality performance many projects fail because of poor performance - 1/3 fails completely - 40% too late or over budget - many of those because of poor performance 4

5 Software Performance Engineering (1) Performance analysis during complete design, starting as early as possible Methods: - performance models (queueing networks, Petri nets) - quantitative methods (MVA) and simulations Build performance into design (don t try to add it later) Current status: accurate modeling of non-distributed systems 5

6 Software Performance Engineering (2) Performance requirements Performance estimates Functional requirements design Architecture coding Refined estimates Working program Performance parameters simulation fine-tuning Finished program 6

7 SPE problems Performance models use dedicated modelling languages - Designers need to learn a new modelling language - Extra models needed => time-consuming - Synchronize changes General-purpose modelling languages lack performance features Solutions: - performance extensions (e.g. UML profiles) - automatic transformations 7

8 Overview Software Performance Engineering SPE + MDA Middleware Transformation Conclusion 8

9 SPE + MDA Many performance details needed -platform - middleware - third-party components -etc. Goal: (semi-) automatic performance evaluation MDA/UML provides necessary features: - solid modelling formalism - different abstraction levels - include component models - model refinement PIM-to-PSM transformation 9

10 Ideal performance modelling process Component library read databasea read client Frontend Front- databasea end write write log log databaseb 10

11 Ideal performance modelling process High-level (UML) model Low-level (UML) model performance model Component information performance estimations 11

12 Overview Software Performance Engineering SPE + MDA Middleware Transformation Conclusion 12

13 Growing system complexity Single computer 13

14 Growing system complexity Single computer Distributed system 14

15 Growing system complexity Single computer Distributed system Distributed system using middleware M I D D L E W A R E 15

16 Middleware Goal: provide interoperability between various components of a distributed system Examples: CORBA, JINI, RMI CORBA benefits: - independence from programming language, architecture, platform - event handling - location transparency (naming service) 16

17 CORBA naming service client server ORB interface stub skeleton ORB interface client ORB network server ORB 17

18 Overview Software Performance Engineering SPE + MDA Middleware Transformation Conclusion 18

19 Input High-level PSM, using UML - collaboration diagram - deployment diagram - activity diagram Description of middleware details - type (e.g. CORBA) - performance information - deployment Naming convention to link the different models together A library of detailed middleware models (can be included implicitly in the transformation algorithm) 19

20 Output Low-level PSM, using UML - several collaboration diagrams - deployment diagram - activity diagram Diagrams contain performance information using the UML Profile for schedulability, performance and time 20

21 Transformation: component names <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> client request continue server waiting process undefined 21

22 Transformation: deployment serverpc server clientpc client NSPC <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> 22

23 Transformation: deployment serverpc server clientpc client corba_client skeleton orb stub NSPC naming_context NS <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> 23

24 Transformation: collaboration orb corba_client client stub skeleton server clientserver clientserver clientserver clientserver clientserver <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> 24

25 Transformation: collaboration corba_client clientserver clientserver clientserver orb client stub skeleton server clientserver clientserver clientserver naming context NS clientserver <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> 25

26 Transformation: activity, input client request server waiting process continue undefined <middleware> <link id="link1" type="corba" NSref="NS1"> <call cref="g.9" /> </link> <NS id="ns1" host="xmi.17" /> </middleware> 26

27 Transformation: activity initialization get server reference (Naming Service) call server -stub -skeleton destroy orb and clean up 27

28 Transformation: activity, initialization client corba_client call_init orb naming context NS initialize call_resolve do_resolve resolve reply call_client request 28

29 Transformation: activity, call client stub skeleton server request stub_request waiting skeleton_request process skeleton_reply dummy stub_reply undefined 29

30 Transformation: activity, destroy client dummy continue corba_client call_destroy return_client orb destroy 30

31 Transformation: activity complete client corba_client orb naming NS stub skeleton server context waiting call_init initialize call_resolve call_client do_resolve reply resolve request stub_request skeleton_request process skeleton_reply stub_reply dummy undefined call_destroy destroy return_client continue 31

32 Transformation: performance Performance modelling using performance profile Actions get the <<Pastep>> stereotype Execution times: Pademand tagged value <middleware> <link id="link1" type="corba" NSref="NS1 inittime= nscalltime= 0.45 destroytime= 3.36 > <call cref="g.9" stubtime= 1.84 skeletontime= 0.10 /> </link> <NS id="ns1" host="xmi.17" lookuptime= 0.53 /> </middleware> 32

33 Transformation: activity final client request corba_client orb naming NS stub skeleton server context call_init call_resolve call_client initialize <<PAstep>> {PAdemand=('assm', 'mean', (36.549,'ms'))} do_resolve reply <<PAstep>> {PAdemand=('assm', 'mean', (0.4597,'ms'))} resolve <<PAstep>> {PAdemand=('assm', 'mean', (0.53,'ms'))} stub_request <<PAstep>> {PAdemand=('assm', 'mean', (1.8413,'ms'))} waiting skeleton_request <<PAstep>> {PAdemand=('assm', 'mean', (0.1021,'ms'))} process skeleton_reply stub_reply dummy undefined call_destroy return_client destroy <<PAstep>> {PAdemand=('assm', 'mean', (3.3646,'ms'))} continue 33

34 The way forward corba client orb naming context client Pc stub Pns NS skeleton Ps p network server 34

35 Test results: response time 2,6 response time time (ms) 2,5 2,4 2,3 2,2 2,1 2 model measurements number of clients 35

36 Overview Software Performance Engineering SPE + MDA Middleware Transformation Conclusion 36

37 Conclusion Automatic inclusion of CORBA performance information during PIM-to-PSM transformation Allows early assessment of the performance impact of using CORBA, without knowledge of the CORBA internals Easily adaptable to other middleware types (allowing the designers to compare several types) 37