Your SlideShare is downloading. ×
Perfomance Problem Sind Architektur Probleme
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Perfomance Problem Sind Architektur Probleme

263
views

Published on

Software Architekten müssen sich heutzutage nicht nur mit klassischem Software Design beschäftigen. Mehr und mehr integrieren sie verschiedenste Services und Systeme zu massiv verteilten …

Software Architekten müssen sich heutzutage nicht nur mit klassischem Software Design beschäftigen. Mehr und mehr integrieren sie verschiedenste Services und Systeme zu massiv verteilten Gesamtapplikationen. Performance kommt hier unter dem allgemeinen Zeitdruck oft zu kurz; aber eine verteilte Architektur skaliert doch, oder?

Presented by Michael Kopp, Product Evangelist, dynaTrace-Compuware Center of Excellence, at the SET Conference, May 2010

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
263
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Es wird mehr Software reingineered als neu geschrieben Ein Architect muss sich mit der Integration von bestehnder, neuer und externer Software beschaefitgen Complex, Zeitdruck
  • Mehr reinginieering und Integration als je zuvor
  • Es wird mehr Software reingineered als neu geschrieben Ein Architect muss sich mit der Integration von bestehnder, neuer und externer Software beschaefitgen Mehr mit weniger. Wer hat da schon Zeit sich auch noch mit Performance auseinanderzusetzten.
  • Dementsprechend sieht der Zeitplan meistens so aus Test anteil wird immer groesser, da die test complexitaet immer groesser wird. Im performance Bereich wird das meistens ignoriert. Die frage ist warum das so ist. Die Komplexitaet ist nicht weniger gross und der Impact aufs design meist groesser der Performance Testanteil bleibt meistens gleich Komplexitaet wird unterschaetzt Fehleinschaetzungen
  • Falsches Mindset heutzutage Performance wird hier oft mit dem Argument vernachlaesigt das die Architektur skaliert. Was aber heisst Scalierbarkeit Fuehrt gleich zu mehreren Problemen
  • Ein weiteres Problem ist das heute Leistung als endlos empfunden wird. In meiner alten Firma hab ich oft “CPU is a given” Die kommende Cloud revolution macht das ganze noch problematischer
  • CPU is a given Zur verfuegungstaehnde Resourcen werden ueberschaetzt CPU is a given, speed is a given Memory is a given Es skaliert eh Falsche Antwort
  • Performance Probleme werden unterschaetzt Es ist schwierig gute Performance in so komplexen system zu erreichen Zuviele hops, latenzen, CPU Kurze Antwortzeiten, laest sich durch skalierbarkeit nicht verbessern, schlechte skalierbarkeit wirkt sich negative auf performance aus
  • Tatsache ist das trotz allem die system oft nur in der Theory skalieren. Hoher Durchsatz Was auch oft vergessen wird ist das Schlecht performance nocht so grosse Skalierbarkeit vernichtet Und noch eines, selbst wenn man ein sein system wirklich fuer viel last ausgelegt ist, wird oft gerne vergessen das die Last nicht gleich verteilt ist. Bottlenecks sind oft misverstanden. Bottlenecks sind nicht nur Skalierbarkeitsprobleme, sondern Performanceprobleme. In diesem fall hier skaliert das system sehr gut, egal wieviele zollstationen gleichzeitig benutzt werden das hat auf den einzelnen keinen einfluss. Aber jeder einzelne ist langsam und somit ist das ganz system langsam.
  • Probleme bauschen sich gegeseitig auf. Mann sieht dann oft den Wald vor lauter Baeumen nicht. Und weiss nicht mehr wo man Anfangen soll. Und am Ende des Projektes trifft man dann auf den Eisberg und es ist noch viel mehr aufwand Woran liegt das, nun meiner Meinung nach hat das verschieden Ursachen, und eines der Prominentesten scheint eine Fehleinschaetzung bei Architekten zu sein.
  • Es ist ein sehr grosser teil der Qualitaet und oft auch ein bestandteil der funktionalitaet an und fuer sich.
  • Was sind ueberhaupt die Anforderungen.
  • Es faengt also bei den Requirements an Zuallerestmal sollten diese genau definiert werden. Nur wenn Bekannt ist was zu erreichen ist, kann auch dafuer geplannt werden
  • Was ist mit 50% requests als erwartet Menschen von Natur aus beschaeftigen sich nicht gerne mit dem Worstcase. Es ist leichterauf ein Ziel hinzuarbeiten.
  • Nicht nur die Software und Performance Requirements an und fuer sich sind wichtig, auch die Umgebung und Hardware requirements sind von bedeutung. Oft wird ein Softwaresystem geplannt ohne ueber die tatsaechlich deployte Umgebung nachzudenken. Natuerlich muessen wir heutzutage viele verschiedene umgebungen unterstuetzen aber es macht einen Unterschied ob es sich um ein oder mehrere Datacenter handelt. Auf wievielen Machinen soll sie laufen und wieviele glauben wir das wir brauchen, global verteilt?
  • Durch die komplexitaet mancher systeme wird immer wieder behauptet das man sie nicht testen kann bevor sie fertig sind. Meiner Meinung ist das ein zeichen von Schlechtem design. CI hat das erkannt CAPM setzt das fort Ein guter Punkt ist ob Agile Entwicklung und Architektur zusammen passt. Meiner Meinung nach ist das die falsche frage
  • Dementsprechend sieht der Zeitplan meistens so aus Test anteil wird immer groesser, da die test complexitaet immer groesser wird. Im performance Bereich wird das meistens ignoriert. Die frage ist warum das so ist. Die Komplexitaet ist nicht weniger gross und der Impact aufs design meist groesser der Performance Testanteil bleibt meistens gleich Komplexitaet wird unterschaetzt Fehleinschaetzungen
  • CAPM
  • Das Stichwort lautet Testbarkeit einer Architektur ist wichtig! Da hilft uns nun eigentlich die doch typische Service artige oder Componenten artige struktur heutiger Software Projekte. Make it run fast Sobald als moeglich testen der Einzelkomponenten test
  • CAPM Performance bedingt oft das das Design angepasst werden muss, das ist leichter im Entwicklungszyclus als am schluss.
  • Scalability heist das die Performance gleich bleibt obwohl mann mehr concurrent action setzt oder groessere aktionen setzt. Daher skalierbarkeit brauch als basis die performance tests. Stead vs steigende last. Herausfinden wo es bricht. Ganz wichtig, ein Skalierbarkeitstest sollte soweit gehen bis das system bricht, oder weit ueber dem ist was noetig ist.
  • Abhaengigkeiten verstehen, firewalls, virtualization
  • Transcript

    • 1. Performance Probleme sindArchitektur Probleme Michael Kopp Technology Strategist and Evangelist
    • 2. Software Evolution MainframeRIA SOA Business Logic Database Systems Virtualization Presentation Clients Web Services Cloud
    • 3. Altlasten
    • 4. Convergence of Complexity Who understands the dependencies & side effects and performance implications? MainframeRIA SOA Business Logic Database Systems Virtualization Presentation Clients Web Services Cloud
    • 5. Der Projektplan Go Live DateE ffort (Mandays ) Development Tes ting Performance Production
    • 6. Skalierbarkeit
    • 7. Leistung ist endlos…
    • 8. Was ist Skalierbarkeit? “scalability is a system’s ability to either handle growing amounts of work in a graceful manner or to be readily enlarged.” “scalability is a system’s ability to either handle growing amounts of work in a graceful manner or to be readily enlarged, at a cost threshold under which you are willing to perform the scaling.”
    • 9. Performanc e ≠ S c alability
    • 10. Theorie und Realität
    • 11. • Negative Performance und Skalierbarkeit verstaerken sich• Positive Skalierbarkeit und negative Performance bedeutet immer schlechte Performance• Negative Skalierbarkeit und positive Performance bedeutet oft schlechte Performance
    • 12. Verteilte Architektur
    • 13. Performance ist wesentlicherBestandteil funktionierender Software
    • 14. Requirements
    • 15. Anforderungen definieren Volumen Antwortszeit Erwarteter Zuwachs Transaktionsverteilung Durchsatz
    • 16. Aim high … … 50% mehr
    • 17. Ac h t e a u f d ie U m g e b u n g
    • 18. Nicht alles am Schluss
    • 19. Plan Go Live DateE ffort (Mandays ) Development Tes ting Performance Production
    • 20. Realität Performance Thres holdManagementPerformance Traditional Time Development Tes ting Production
    • 21. The dynaTrace Approach
    • 22. T e s t b a r e s D e s ig n• Einzelkomponenten muessen testbar sein• Testbare User stories und Use Cases• Automation ist der Schluessel (CI und CAPM)• Make it run
    • 23. Granularität Vergleichbarkeit Komplexität Qualität
    • 24. Änderungen sofort … v3.0 - initial results v3.1 - wrong caching strategy - Bugfixes with Performance Impact - Performance Improvement … sehen
    • 25. Welcher Checkin ist verantwortlich Version Control History Lookup
    • 26. Frequency vs. Granularity JUnit-based Tests (2x day)Granularity Long-running Total System Stabiltiy Tests Tests (2 w duration) Frequency
    • 27. A rchitekturvalidierung
    • 28. Architektur Review• Überprüfung wesentlicher Kriterien der Anwendung • Datenbankzugriffe • Kommunikationsmuster • Übertragene Datenmenge • Speicherverbrauch• Als Teil von Coderreviews• Aufwand 1-2 h pro Use Case• Validation automatisieren
    • 29. Verteilung/Kommunikation
    • 30. Datenbankzugriffe Application C onnection getConnection() Application Connection locked sel ... where id= 1 ect sel ... where id= 1 ect closeConnection() Application C onnection getConnection() sel ... where id= 1 00 ect Code requiring DB access Connection locked closeConnection() Code NOT requiring DB access Database N+1 Query/Too many SQLs Unnecessary Resource UsageApplication select ... from master select ... from detail select ... from detail select ... from detail Database Application select ... from master, detail where .. Database Lazy vs. Eager Loading Loading too much data
    • 31. Testing scalability vs. Testing performanceSmall Dump Operations Big Dump Operations
    • 32. Analye automatisieren … … Fokus auf Lösung
    • 33. Instabilität erzeugen .. adding some volatility increases the likelyness to discover problems …“
    • 34. „Last Mile Testing“
    • 35. Produktionsdatenanalyse• Produktionsdaten sind realer als jeder Lasttest• Verständnis für Antwortzeiten und Lastverhalten• Verständnis für Architektur im Echtsystem• Wer Trends versteht, kann Problemen vorbeugen
    • 36. Performance Thres holdManagementPerformance Traditional Time Development Tes ting Production C ontinuous Performance Performance Thres hold Management Time Development Tes ting Production
    • 37. michael.kopp@dynatrace.c om Mail
    • 38. Download the latest Application Performance almanac:Web | Cloud | DevOps | Mobile | Automation | Tuningwww.dynatrace.com/almanac