Design Objectives and Design Understandability

Transcription

1 by Gerrit Muller University of South-Eastern Norway-NISE Abstract The complexity of systems limits the understanding by the architect of the impact of changes. Many objectives are pursued, from customer needs to implementation lessons learned, while designing a system. From architecting perspective understandability of the design is an important issue. Some design choices may create very efficient systems, but might be difficult to grasp. For example simple local autonomy might prove to be efficient and robust, but at the same time other system qualities are emerging and difficult to predict. We discuss the notion of understandability, illustrated by a number of design patterns. Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: planned logo TBD

2 Figure Of Contents TM 1 performance example: do we understand our design? 2 What does Customer need in Product and Why? Customer objectives Application Functional Conceptual Realisation complexity of context and system abstraction How can the product be realized What are the critical decisions number of details system requirements design decisions parts connections lines of code and growing every year... application network cache layer file cache virtual cache caches L1, L2, L3 3 application network cache layer file cache virtual cache caches L1, L2, L3 scree n back office serve r scree n mid office serve r network network scree n application network cache layer file cache virtual cache caches L1, L2, L3 Load(h) = 2000 * 1[ms] * h * 1.98[ms] Load(h) = * h [ms] cache example; impact of autonomous low-level mechanism on performance 4 load in seconds discussion and conclusion 1 2 t quantified mid office server h = 0.02 ms t example m = 2 ms to be measured n a = 1000 hit rate also! utilizable capacity Hit rate is context dependent. Life cycle changes or peak loads may degrade hit rate. 0.5 Hit rate of well designed system is ample within working range (e.g. 95%) 0 e order formula is valid: Load = 0.02 * n a [ms] working range hit rate 1 2 Gerrit Muller DODUlogo

3 Image Retrieval Performance application need: at event 3*3 show 3*3 images instanteneous design Sample application code: for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } design or alternative application code: event 3*3 -> show screen 3*3 <screen 3*3> <row 1> <col 1><image 1,1></col 1> <col 2><image 1,2></col 2> <col 3><image 1,3></col 3> </row 1> <row 2> <col 1><image 1,1></col 1> <col 2><image 1,2></col 2> <col 3><image 1,3></col 3> </row 1> <row 2> <col 1><image 1,1></col 1> <col 2><image 1,2></col 2> <col 3><image 1,3></col 3> </row 3> </screen 3*3> 3 Gerrit Muller PINTROsampleCode

4 Straight Forward Read and Display What If... Sample application code: for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } UI process screen store 4 Gerrit Muller PINTROwhatIf1

5 More Process Communication What If... Sample application code: UI process 9 * update 9 * retrieve screen server for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } screen database 5 Gerrit Muller PINTROwhatIf2

6 Meta Information Realization Overhead What If... Sample application code: Meta Attributes Image data for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } Attribute = 1 COM object 100 attributes / image 9 images = 900 COM objects 1 COM object = 80µs 9 images = 72 ms UI process database 9 * update 9 * retrieve screen server screen 6 Gerrit Muller PINTROwhatIf3

7 I/O overhead What If... Sample application code: - I/O on line basis (512 2 image) for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } * 512 * t I/O t I/O ~= 1ms 7 Gerrit Muller PINTROwhatIf4

8 Non Functional Requirements Require System View Sample application code: for x = 1 to 3 { for y = 1 to 3 { retrieve_image(x,y) } } can be: fast, but very local slow, but very generic slow, but very robust fast and robust... The emerging properties (behavior, performance) cannot be seen from the code itself! Underlying platform and neighbouring functions determine emerging properties mostly. 8 Gerrit Muller PINTROconclusionWhatIf

9 Function in System Context usage context F & S F & S F & S MW MW MW MW OS OS OS F & S F & S F & S F & S F & S Functions & Services performance and behavior of a function depend on realizations of used layers, functions in the same context, and the usage context Middleware Operating systems HW HW HW Hardware 9 Gerrit Muller PINTROconclusion

10 Challenge F & S F & S F & S F & S F & S F & S F & S MW MW MW MW OS OS OS HW HW HW F & S Functions & Services Middleware Operating systems Hardware Performance = Function (F&S, other F&S, MW, OS, HW) MW, OS, HW >> 100 Manyear : very complex Challenge: How to understand MW, OS, HW with only a few parameters 10 Gerrit Muller PINTROproblemStatement

11 1 performance example: do we understand our design? What does Customer need in Product and Why? Customer objectives How can the product be realized What are the critical decisions Application Functional Conceptual Realisation number of details system requirements design decisions parts connections lines of code and growing every year... application network cache layer file virtual cache cache caches L1, L2, L3 3 application network cache layer file cache virtual cache caches L1, L2, L3 scree n back office serve r scree n mid office serve r network network scree n application network cache layer file cache virtual cache caches L1, L2, L3 load in seconds Load(h) = 2000 * 1[ms] * h * 1.98[ms] Load(h) = * h [ms] cache example; impact of autonomous low-level mechanism on performance 1 2 t quantified mid office server h = 0.02 ms t example m = 2 ms to be measured n a = 1000 hit rate also! utilizable capacity Hit rate is context dependent. Life cycle changes or peak loads may degrade hit rate. 0.5 Hit rate of well designed system is ample within working range (e.g. 95%) 0 e order formula is valid: Load = 0.02 * n a [ms] working range hit rate 1 2 complexity of context and system abstraction 4 discussion and conclusion 11 Gerrit Muller DODUlogoComplexity

12 Exponential Pyramid, from requirement to bolts and nuts number of details system requirements design decisions parts connections lines of code research focus system multi- disciplinary mono- disciplinary 12 Gerrit Muller IALApyramid

13 Major Bottleneck: Mental Dynamic Range stretch number of details stretch monodisciplinary subsystem or function stretch system Gerrit Muller ATmentalDynamicRange

14 Organizational Problem: Disconnect What does Customer need in Product and Why? Customer objectives Application Functional Conceptual Realisation gap system requirements design decisions How can the product be realized What are the critical decisions parts connections lines of code and growing every year Gerrit Muller RATWdisconnect

15 Architect: Connecting Problem and Technical Solution What does Customer need in Product and Why? How can the product be realized What are the critical decisions Customer objectives Application Functional Conceptual Realisation number of details system requirements design decisions parts connections lines of code and growing every year Gerrit Muller RATWbreadthAndDepth

16 1 2 performance example: do we understand our design? What does Customer need in Product and Why? Customer objectives Application Functional Conceptual Realisation cache complexity of context and system abstraction How can the product be realized What are the critical decisions number of details system requirements design decisions parts connections lines of code and growing every year... application network cache layer file cache virtual cache caches L1, L2, L3 application network cache layer file cache virtual cache caches L1, L2, L3 3 scree n back office serve r scree n mid office serve r network network scree n application network cache layer file cache virtual cache caches L1, L2, L3 load in seconds 1 2 t quantified mid office server h = 0.02 ms t example m = 2 ms to be measured n a = 1000 hit rate also! Load(h) = 2000 * 1[ms] * h * 1.98[ms] Load(h) = * h [ms] utilizable capacity Hit rate is context dependent. Life cycle changes or peak loads may degrade hit rate. 0.5 Hit rate of well designed system is ample within working range (e.g. 95%) 0 e order formula is valid: Load = 0.02 * n a [ms] working range example; impact of autonomous low-level mechanism on performance 4 discussion and conclusion hit rate 1 16 Gerrit Muller DODUlogoCacheExample

17 Typical Block Diagram and Typical Resources in IT screen screen screen legend web server network network presentation computation communication data base server storage 17 Gerrit Muller MAFTgenericBlockDiagram

18 Hierarchy of Storage Technology Figures of Merit latency capacity processor cache L1 cache L2 cache L3 cache sub ns ns n kb n MB fast volatile main tens ns n GB persistent disks disk arrays disk farms ms n*100 GB n*10 TB archival robotized optical media tape >s n PB 18 Gerrit Muller MAFTstorage

19 Performance as Function of Data Set Size random data processing performance in ops/s L1 cache L3 cache main hard disk disk farm robotized media data set size in bytes 19 Gerrit Muller MAFTstoragePerformance

20 Multiple Layers of Caching application cache network layer cache file cache virtual caches L1, L2, L3 cache miss penalty 1 s 100 ms 10 ms 1 ms 100 ns cache hit performance 10 ms 1 ms 10 µs 100 ns 1 ns typical cache 2 orders of magnitude faster application cache network layer cache file cache virtual caches L1, L2, L3 application cache network layer cache file cache virtual caches L1, L2, L3 screen screen screen back office server mid office server network network application cache network layer cache file cache virtual caches L1, L2, L3 20 Gerrit Muller MAFTgenericCaches

21 Why Caching? project risk performance response time long latency mass storage long latency communication limit storage needs to fit in fast local storage low latency low latency less communication frequently used subset fast storage local storage design parameters caching algorithm storage location cache size life cycle cost overhead communication resource intensive processing latency penalty once overhead once processing once chunk size larger chunks format in (pre)processed format 21 Gerrit Muller MAFTwhyCaching

22 Example Web Shop screen screen screen network web server network consumer browse products order pay track exhibit products sales & order intake order handling stock handling financial bookkeeping enterprise logistics finance product management customer managment customer relation management update catalogue advertize after sales support data base server product descriptions logistics ERP financial customer relations 22 Gerrit Muller MAFTexampleWebShop

23 Impact of Picture Cache screen screen screen fast response network back office server mid office server network product descriptions less load less server costs less load less server costs logistics ERP financial picture cache customer relations 23 Gerrit Muller MAFTwebShopPictureCache

24 Risks of Caching frequently used subset fast storage robustness for application changes ability to benefit from technology improvements life cycle cost effort local storage larger chunks in (pre)processed format robustness for changing context (e.g. scalability) robustness for concurrent applications failure modes in exceptional user space project risk cost effort performance 24 Gerrit Muller MAFTrisksOfCaching

25 Zero Order Load Model zero order web server load model Load = n a * t a n a = total requests t a = cost per request 25 Gerrit Muller MASMloadZeroOrder

26 First Order Load Model first order web server load model Load = n a,h *t h + n a,m *t m n a,h = accesses with cache hit n a,m = accesses with cache miss t h = cost of cache hit t m = cost of cache miss n a,h = n a * h n a,m = n a * (1-h) n a = total accesses h = hit rate Load(h) = n a * h* t h + n a * (1-h) * t m = n a * t m - n a * h * (t m - t h ) 26 Gerrit Muller MASMloadFirstOrder

27 Quantification: From Formulas to Insight t h = 0.02 ms quantified mid office server example load in seconds 2 t m = 2 ms n a = 1000 Load(h) = 1000 * 2[ms] * h * 1.98[ms] Load(h) = * h [ms] 1 utilizable capacity working range 0.5 hit rate 1 27 Gerrit Muller MASMquantified

28 Hit Rate Considerations load in seconds 2 quantified mid office server example t h = 0.02 ms t m = 2 ms n a = 1000 to be measured hit rate also! Load(h) = 1000 * 2[ms] * h * 1.98[ms] Load(h) = * h [ms] Hit rate of well designed system is ample within working range (e.g. 95%) 0 th order formula is valid: Load = 0.12 * n a [ms] 1 utilizable capacity working range Hit rate is context dependent. Life cycle changes or peak loads may degrade hit rate. 0.5 hit rate 1 28 Gerrit Muller MASMdiscussion

29 Response Time human customer press next look web server request picture check cache request picture store in cache transfer to transfer process display data base server retrieve picture t 0 t t t t t t t time in milliseconds in optimal circumstances 29 Gerrit Muller MASMresponseTime

30 1 performance example: do we understand our design? 2 What does Customer need in Product and Why? Customer objectives Application Functional Conceptual Realisation complexity of context and system abstraction How can the product be realized What are the critical decisions number of details system requirements design decisions parts connections lines of code and growing every year... application network cache layer file cache virtual cache caches L1, L2, L3 3 application network cache layer file cache virtual cache caches L1, L2, L3 scree n back office serve r scree n mid office serve r network network scree n application network cache layer file cache virtual cache caches L1, L2, L3 Load(h) = 2000 * 1[ms] * h * 1.98[ms] Load(h) = * h [ms] cache example; impact of autonomous low-level mechanism on performance 4 load in seconds 1 2 t quantified mid office server h = 0.02 ms t example m = 2 ms to be measured n a = 1000 hit rate also! utilizable capacity Hit rate is context dependent. Life cycle changes or peak loads may degrade hit rate. 0.5 discussion and conclusion Hit rate of well designed system is ample within working range (e.g. 95%) 0 e order formula is valid: Load = 0.02 * n a [ms] working range hit rate 1 30 Gerrit Muller DODUlogoDiscussion

31 Some Understandability Propositions central full control does not imply understandability delegated autonomous behavior does not imply understandability a few simple rules can create very complex behavior understanding does not imply determinism or predictability valid abstractions facilitate understanding simulations provide numbers, not understanding only humans understand! 31 Gerrit Muller DODUpropositions

32 Conclusions control, predictability, and determinism are illusions simple rules can create complex non-understandable systems challenge: to model systems at " right " abstraction level 32 Gerrit Muller DODUconclusions