Your SlideShare is downloading. ×
Soa Performance in der Realitat Alles Schnell und Doch Langsam
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

Soa Performance in der Realitat Alles Schnell und Doch Langsam

333

Published on

SOA und BPM entkoppeln Business und Applikationslogik. Was aber heißt das für Performance? In einer SOA oder einem BPM Environment hängt die Performance stark vom Deployment und der Orchestration ab. …

SOA und BPM entkoppeln Business und Applikationslogik. Was aber heißt das für Performance? In einer SOA oder einem BPM Environment hängt die Performance stark vom Deployment und der Orchestration ab. Diese sind dem Entwickler aber oft nicht bekannt und das macht Performanceanalysen schwierig. Es wird auch behauptet das eine SOA schon vom Prinzip her skalierbar ist. Oft müssen Architekten dann feststellen, dass das nicht bedeutet dass die Anwendung auch schnell ist. Wir werden die typischen Performance Fehler in einer SOA besprechen und aufzeigen wie man diese identifizieren und analysieren kann. Nach diesem Vortag werden sie verstehen warum ihre Produktionsperformance manchmal trotz erfolgreicher Performancetests schlecht sein kann.

Presented by Michael Kopp, Product Evangelist, dynaTrace-Compuware Center of Excellence, WebTechCon, October 2011

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
333
On Slideshare
0
From Embeds
0
Number of Embeds
1
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
  • Massive Transaction Flow
  • Sample Data: smalldatabaseswith sample datais not realistic. Canttestcaching, access time todatabase, …OverloadedAgents: LoadTestingAgentsare just usedtoproduceloadwithoutverifyingiftheycanproducetherequestedloadWrong Think Times: Think Times areeither not setcorrectlytoreflect real usersortheyareavoidedtoincreaseload -> thats not realisticeitherInfrastructure Issues: doesthe Test Infrastructure provideenoughbandwidth, resources, … to handle theload? Isthereanythingelserunning on theinfrastructurethatmayinterfere?No Error Detection: Missing Content Verificationleadstoincorrectresults. A Page thatresponds super fast but alwaysyresponds „pleasecome back later“ is a problemNo Server Side Data: veryoftenpeopleforgettocollectserversidemetrics such as CPU, Network, I/O, Logfiles, …
  • instability
  • In ordertoidentifyproblematiccomponentsorservicesitsrecommendedtorun different loadandseewhichcomponentsscaleandwhichdont
  • Toomucheffortforscriptmaintenance, settingupthetestenvironmentCostsfortestingtoolsandtestenvironmentTest cycletakeslongerthanreserved in thesprint. Feedback todevscomeswhentheyarealready in thenextsprint
  • In traditional developmentwehopedthatloadtestingisthesilverbulletto find performanceproblems. Today weseethatthisis not thecase. Let‘slookintothedetailswhyweneed a newwayoftesting.
  • Rerun, additional dataAdding log statemetnsandstatistics in code, errorprone.First, automatethestuff.Second, captureenoughfromthebeginning. (traces, BTM)Dynamic Capture all the time.Overhead discussion 5-10Benefits of Agile and DevOpsShorter iterations with fewer changes leads to reduced effort in testingfewer script maintenance changes, higher quality smoke test, easier regression analysis,more focused testing on the areas that have changed
  • Oneofthekeythingstounderstandthatthereis a differencebetweenperformancetrackingandperformancetesting. Performance testingis a oneshotthing, andwelookat absolute numbersandifwemeetthegoal. The problemisthatifwedon‘twehavetoinvestigatewhywedon‘tTracking on theotherhandisaboutchange. Andifwetrackperformanceandtrackthechangethanwedon‘treallyhavetoinvestigae. Ifsomethinggetsslowerthanweknowthatthisis not good.
  • Testdrivendevelopment. (usecase!)Automatic, Detect Change, AnalyzeArchitectureWeshouldhave a trendingcharthere.Perfearly, insidethecycle. This wayitispartofthesprint not outside. Itisautomted so itdoes not introduce additional effort.Be in Control!
  • Be In Control, earlyandautomatic.
  • All ofthisleadsto …I am done – nowyoudeployit
  • Transcript

    • 1. Michael Kopp| dynaTraceSOA Performance in der Realität:Alles schnell und doch langsam
    • 2. Theorie• Einfachere Entwicklung• Nutzung existierender Services• Unabhängiges Deployment• Prozess Logik Unabhängig entwickeln• Architektur Skaliert Geschäfts und Prozessgetrieben
    • 3. Realität
    • 4. Realität• Lange Zyklen• Komplexe Umgebungen• Fehler durch Service Abhängigkeiten• Performanceprobleme• Skalierbarkeitsprobleme IT getrieben
    • 5. Performance Probleme• Zuviel Kommunikation• Unerwartete Hotspots• Schlecht verstandene Seiteneffekte• Performance und Fehleranalyse oft schwierig• Falle Skalierbarkeit
    • 6. Warum ist das so?• SOA/BPEL Everything• Unbekannter Ablauf• Abhängigkeiten der Services• Nicht optimiert für Produktionsabläufe• Deployment ignoriert Abhängigkeiten
    • 7. ÜBERWACHUNG UNDERKENNUNG
    • 8. Bottleneck – Serviceframework• Service Aufruf • Remote • Lokal • Data Mapping Performancebottleneck nicht „Teil“ des Service, sondern Teil des Process Verursacht durch Service
    • 9. Bottleneck Service• Kontext Abhängig (Prozess, Daten)• Auswirkungen • auf Prozess • Aufrufende Services • Resourcenverbrauch
    • 10. Fachlicher Kontext
    • 11. Reverse Abstraction• Business (Teil) Prozesse/ Transactions • Technischer Service Flow • Performance • Errors
    • 12. Service Sicht• Services für einen Prozess• Kein Averaging Effekt
    • 13. Details, Details, Details
    • 14. Symptome, Ursache und Wirkung Ein Symptom auf einem Service oder einer JVMImpact auf eineBusinessTransaction, einenBusiness Prozess
    • 15. Deployment neuer Services• Abhängigkeiten erkennen• Impact erkennen• Regressions erkennen
    • 16. Performance Antipatterns• Blinde Verteilung• Connect Everything• Allmächtiges Domain Model• Kontextloses Monitoring • Antwortzeiten of Service Ebene
    • 17. Performance Best Practices• Deployment/Prozess Alignment• Performance Monitoring • Business Prozess  Service Flow  Details• Grobe Business Services • Weniger Kommunikation • Weiniger Daten Mapping
    • 18. TESTEN
    • 19. Vorteile einer SOA• Genau Definierte Services • Funktionales Testen einfach • Performance Testen?• Abhängigkeiten? • Keine (IOC) • Simulation?
    • 20. Lasttests = Integrationstests
    • 21. Häufige FehlerNur Sample Daten und Prozesse Keine Server DetailsFalsche “Denk” Zeiten Überladene AgentenKeine Fehler Erkennung Infrastructure Probleme
    • 22. Echte ScenariosEchte ProzesseEchte DatenEchte Last Kein Mocken beim Last Testen! Echtdaten aus Produktion als Ausgangspunkt
    • 23. Skalierbarkeitsprobleme Response time Presentation Layer Presentation Layer Business Logic Presentation Layer Business Logic Business Logic Web Service/Remoting Web Service/Remoting Web Service/Remoting Data Access Data Access Data Access Minimum Load Medium Load Maximum Load
    • 24. Volatilität für Stabilität
    • 25. Lasttesten dauert…zu Lange Zeit Last Test Team 1 Update Test Setup Testlauf Scripts Environment Scripts anpassen 2. Testlauf Feedback an R&D Testen dauert länger Last Test Team 2 3. Testlauf Feedback an R&D Releasefähig Release verschoben Risiko von schlechter Performance?
    • 26. Tip: Keine Wiederholungen• Was könnte alles passieren?• Welche Daten brauchen wir?• Was beschreibt das System?• Unterschied zum letzten Lauf?
    • 27. Load Testing ≠Silver Bullet
    • 28. “Minimal“ und AutomatisiertEntwicklung Test Run Reproduction Refine Capturing Re Run Tests Reproduction Refine Capturing Multiple Test Iterations needed to analyze Root-cause Re Run Tests Reproduction Problem Analysis Problem Solving timeEntwicklung Test Run Reproduction Refine Capturing Re Run Tests Reproduction Refine Capturing •Eliminates Test Iterations •Go directly to problem analysis •Frees up resources for other proje Re Run Tests Reproduction Problem Analysis Problem Solving time
    • 29. PERFORMANCEENGINEERING
    • 30. Kontinuierlich und Automatisiert
    • 31. Performance Tracking vs.Performance Testing
    • 32. Was heist das?• Kontrolliert (Früherkennung)• Architekturanalyse• Abhänigkeiten erkennen• Prozess über den gesammten Zyklus
    • 33. Continuous Integration
    • 34. Erkennung von Regressionen
    • 35. Architecture Validation Analysieren existierender Unit Tests Automatische Validation
    • 36. Prozess• Produktionsdaten treiben Performance Engineering• “Echtes” Lasttesten mit Tradeoff• Performance während Entwicklung auf Basis von Produktionsdaten• Anpassung der Architektur an echt Scenarios• Intelligentes Deployment
    • 37. Kommunikation ist der SchlüsselSource:
    • 38. Michael Koppmichael.kopp@dynaTrace.comhttp://blog.dynatrace.com@mikopp
    • 39. Nicht versäumen! LIVE Webinare – Kunden berichten Risikoloses Testen in Lasttests automatisieren – ECommerce Systeme & User Produktion Effizienz und Qualität steigern. Experience optimieren Transparenz schaffen und Performance Killer identifizieren Testzyklen beschleunigen! So vermeiden Sie unzufriedene Nutzer! und beseitigen!Key Take Aways: Key Take Aways: Key Take Aways:• Skalierbarkeit und die Einhaltung • Verkürzen und beschleunigen von • Performance Killer im Livebetrieb pro aktiv von SLA´s gewährleisten Testzyklen durch Automatisierung identifizieren und beseitigen• eBusiness in Realtime analysieren • End-to-End Transparenz für alle • Geschäftskritische Click Pfade und optimieren Transaktionen sicherstellen identifizieren und Umsätze steigern• Regressionen verhindern • Release ohne Risiko • Langsames Web 2.0 Browserscripting• Performance Engpässe frühzeitig • Regressionen identifizieren, erkennen und beheben erkennen, stabilere Releases beseitigen und zukünftig vermeiden • Tieftechnische Performance Analyse mit erzielen • Testabdeckung bei steigender Business Monitoring auf einem Dashboard• Kritische „landing pages“ und „page Komplexität erhöhen • User Experience im Vergleich zum actions“ identifizieren und Mitbewerb oder industrieweit messen optimieren Do, 10.11.2011 Do, 24.11.2011 Do, 06.12.2011 10:00 – 11:00 Uhr 10:00 – 11:00 Uhr 10:00 – 11:00 Uhr http://www.dynatrace.com/de/FutureWebinars.aspx
    • 40. Java Performance Challenge – Win an iPad 2http://tinyurl.com/dTCodeSoaBpm
    • 41. Download the latest Application Performance almanac:Web | Cloud | DevOps | Mobile | Automation | Tuningwww.dynatrace.com/almanac

    ×