Analyzing performance of concurrent usage scenarios using software architecture analysis

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

2. Outline • Motivation • Available software architecture -based performance analysis methods • Typical process • Purpose • Requirements • Methods • Method overview • Example analysis • Conclusions

3. 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 • Software architecture -based approach: • 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 Requirements Analysis Software architecture -based performance engineering Functional Architecture Preliminary Design Detail Design Coding Unit Testing Integration Testing Traditional performance engineering Maintenance and Operation

4. Timing Information Software Architecture Transformation Analysis Performance Model Feedback Available software architecture -based performance analysis methods: typical process

5. 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

6. Requirements • 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

7. Available software architecture -based performance analysis methods • - PASA method • as a overal framework • LQN for modelling • RMA principles for performance improvements

8. 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 -> related architectural components -> drawing a LQN model -> calculating utilisation and residence time -> comparing calculated values with performance objectives Performance Modelling and Analysis -> applying performance anti-patterns as an aid to remove bottlenecks from the architecture -> applying RMA principles to guarantee that the most critical tasks will meet their deadlines Performance Improvements

9. Software Architecture Overview DSP Software Symbian Software Bearer Protocols

10. Critical Use Cases, Key Performance Scenariosand Performance Objectives Video stream 40 packets/s Multimedia content 1 packet/s Streaming Content Server Audio stream 10 packets/s Multimedia Service Centre (MMSC) Mobile Phone • Critical Use Cases: • Multimedia streaming • Multimedia message (MMS) • Key Performance Scenarios: • receiving video stream packets • receiving audio stream packets • receiving MMS content packets Performance Objectives: -> max response time 25 ms/packet -> max response time 100 ms/packet -> max response time 1000 ms/packet

11. Architecture Details Video and audio stream packets MMS content packets Bearer Protocols Bearer Protocols IP Stack IP Stack 0.3 ms 0.3 ms UDP Stack 0.35 ms TCP Stack 0.35 ms = 1.85 ms RTP/RTCP Stack 0.2 ms HTTP Stack 2.0 ms = 49.25 ms Multimedia Streaming Player 1.0 ms MMS Server 19.6 ms DSP Software Messaging Server 27.0 ms

12. Performance modelling Video 40 packets/s Audio 10 packets/s Streaming Content 1 packet/s MMS RTP/RTCP Stack 0.2 ms UDP Stack 0.35 ms Multimedia Streaming Player 1.0 ms IP Stack 0.3 ms HTTP Stack 2.0 ms MMS Server 19.6 ms TCP Stack 0.35 ms RTP/RTCP Stack 0.2 ms Processor

13. 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

14. 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 • ... • 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

15. 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.

16. 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/P512.pdf • email: Tarja.Kauppi@vtt.fi, Anu.Purhonen@vtt.fi