Analyzing performance of concurrent usage scenarios using software

Analyzing performance of concurrent usage scenarios using software architecture analysis Tarja Kauppi & Anu Purhonen, VTT Technical Research Centre of Finland 16 th International Conference on Software & Systems engineering and their Applications 2 nd - 4 th December 2003, Paris *

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Outline • Motivation • Available software architecture based performance analysis methods – – Typical process Purpose Requirements Methods • Method overview • Example analysis • Conclusions 3. 3. 2021 * 2

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Motivation • Hardware capacities have grown, however software has become more complex. • Users have greater freedom to start many applications. • Traditional approach: – first implement and then test – if performance problems, then modify Requirements Analysis Preliminary Design Detail Design • Software architecture -based approach: Coding – design the software system so that when it is ready it meets its performance objectives -> no later modifications • Software architecture -based approach is not systematically used in the industry – ad-hoc methods ->results are not comparable and they depend on the experience of the software architect 3. 3. 2021 * Software architecture -based performance engineering Functional Architecture Unit Testing Traditional performance engineering Integration Testing Maintenance and Operation 3

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Available software architecture -based performance analysis methods: typical process Timing Information Software Architecture Transformation Performance Model Analysis Feedback 3. 3. 2021 * 4

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Available software architecture -based performance analysis methods: purpose • predicting the performance of the system, • guaranteeing that performance goals are met, • comparing different architectural choices from performance point of view, • finding bottleneck resources, • identifying potential timing problems, • aid when deciding if the architecture is worth implementation 3. 3. 2021 * 5

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Requirements 1. 2. 3. 4. 5. easy to use and integrate in the software development process, simple modelling approach, tool support available, good instructions and case studies available of applying the method in practice, should help in outlining the problem area 3. 3. 2021 * 6

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Available software architecture -based performance analysis methods - PASA method as a overal framework - LQN for modelling - RMA principles for performance improvements 3. 3. 2021 * 7

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Method Overview Software Architecture Overview -> high level understanding about the architecture Critical Use Cases -> identification of use cases that are important from performance point of view Key Performance Scenarios -> identification of the scenarios that are executed frequently or the ones that are critical from user’s perception of performance Performance Objectives -> at least one quantitative objective is identified to each key performance scenario and condition under which the objectives should be met is defined Architecture Details 3. 3. 2021 * -> related architectural components -> drawing a LQN model Performance Modelling -> calculating utilisation and residence time and Analysis -> comparing calculated values with performance objectives -> applying performance anti-patterns as an aid to Performance remove bottlenecks from the architecture Improvements -> applying RMA principles to guarantee that the most critical tasks will meet their deadlines 8

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Software Architecture Overview DSP Software Symbian Software Bearer Protocols 3. 3. 2021 * 9

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Critical Use Cases, Key Performance Scenarios and Performance Objectives Video stream 40 packets/s Streaming Content Server Multimedia content 1 packet/s Audio stream 10 packets/s Mobile Phone Critical Use Cases: • Multimedia streaming Key Performance Scenarios: Performance Objectives: • receiving video stream packets • receiving audio stream packets • Multimedia message (MMS) • receiving MMS content packets 3. 3. 2021 * Multimedia Service Centre (MMSC) -> max response time 25 ms/packet -> max response time 1000 ms/packet 10

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Architecture Details Video and audio stream packets Bearer Protocols IP Stack MMS content packets Bearer Protocols 0. 3 ms IP Stack 0. 3 ms TCP Stack 0. 35 ms RTP/RTCP Stack 0. 2 ms HTTP Stack 2. 0 ms Multimedia Streaming Player MMS Server 19. 6 ms UDP Stack 0. 35 ms = 1. 85 ms DSP Software 3. 3. 2021 * 1. 0 ms Messaging Server 27. 0 ms 11 = 49. 25 ms

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Performance modelling Video Audio Streaming 40 packets/s 10 packets/s RTP/RTCP Stack 0. 2 ms UDP Stack 0. 35 ms Multimedia Streaming Player 1. 0 ms Content 1 packet/s IP Stack 0. 3 ms HTTP Stack 2. 0 ms MMS Server 19. 6 ms MMS TCP Stack 0. 35 ms Processor 3. 3. 2021 * 12 RTP/RTCP Stack 0. 2 ms

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Analysis Utilisation: Utilisation upper limit for n tasks: Residence time: • Performance objectives are met on average, however performance problems may occur in worst-case situation. – > Changes are not necessarily needed to the system. • Note! The formulas are applicable if – tasks are scheduled according to first-come-first-served or priority scheduling policy – if the system can be considered to be fast enough to handle arrivals 3. 3. 2021 * 13

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Performance improvements RMA scheduling principle: • if utilisation is less than utilisation upper limit, • if tasks are periodic, • they are not synchronised, • they do not suspend themselves during execution, • and they are capable of being preempted by higher priority tasks, • then priorities can be assigned in a way that deadlines are met even in the worst-case situation. Tasks with highest arrival rate -> highest priority Tasks with next highest arrival rate -> next highest priority. . . 3. 3. 2021 * • The conditions could be assumed to be met in this case, so by assigning priorities as follows performance objectives should be met in the worst-case situation. – Video stream (40 packets/s) -> highest priority – Audio stream (10 packets/s) -> next highest priority – MMS content (1 packet/s) -> lowest priority 14

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Conclusions • The approach provides added value to the current software system development. • Quantitative values produced are approximations, however the approach helps to manage the performance of a complex system, because it guides to concentration on the parts that are important from the performance point of view. • Problems: – does the performance model illustrate the system in enough detail? – where to obtain the timing values if nothing can be measured? – how do made assumptions effect on performance? • The approach probably produces best results if the same type of system has earlier been implemented -> timing estimations based on earlier measurements. • If the type of system is developed for the first time, then this kind of quantitative analysis is not meaningful -> using performance anti-patterns as an aid is more rational, because they do not require timing information. 3. 3. 2021 * 15

VTT TECHNICAL RESEARCH CENTRE OF FINLAND Questions • More about the issue: • Kauppi, T. & Purhonen, A. Performance analysis of concurrent usage scenarios using software architecture analysis. ICSSEA 2003, 2 -4 December, Paris. • Kauppi, Tarja. Performance analysis at the software architectural level, VTT Publications 512, Espoo 2003. http//www. vtt. fi/inf/pdf/publications/2003/P 512. pdf • email: Tarja. Kauppi@vtt. fi, Anu. Purhonen@vtt. fi 3. 3. 2021 * 16