The document discusses the importance of monitoring performance in agile development to ensure high-quality applications. It emphasizes challenges with non-functional requirements, the necessity for developers to care about performance, and the need for effective tools in the testing process. It also highlights the shift in development practices towards DevOps and the significance of ongoing performance monitoring throughout the development and production cycles.

1. Monitoring Performance from Development through ProductionAgile Development of HIGH Performance APPLICATIONS

2. Fabian LangeHead of Competence Center PerformanceJava since its beginningAgile since its establishmentPerformance since waiting got boringMeandcodecentriccodecentric AG

3. Specialized in

4. Perfomance Services

5. Agile Software Factory

6. AlwayslookingfornewtalentTable of ContentsChapter One"The curse of non-functional Requirements”Chapter Two“Ensuring Great Performance”Chapter Three“A Real World Example”Chapter Four“The DevOps Revolution"Epilogue

7. The curse of non-functional RequirementsChapter One

8. Who measures performance …in production?before production?during development?Who does development …the waterfall way?the agile way?Let‘s Do a Poll

9. We finally can test functional requirements!Many modern practicesTDDATDDBDDTesting Requirements

10. Executable Specifications makes functional testing a breeze!RequirementsaretheTEst*** Settings ***Resource ${RESOURCES}/BDD.txtTest Template Branch Manager Change Should not affectEmployee*** Keyword ***Branch Manager Change Should not affectEmployee [Arguments] ${periodClosed} ${periodOpenAndModified} ${importDay} ${oldManagerValidUntil} ${newManagerValidFrom}GiveninitializedcriteriaforbonuscommercialAnd a branch B withbranchmanager M_OLD andemployee E1Andevaluationfor E1 forperiod ${periodClosed} whichisclosedAndevaluationfor E1 forperiod ${periodOpenAndModified} whichis open andmodifiedWhen M_NEW becomesnewmanagerofbranch BAndimportserviceiscalled on ${importDay}Thenthenewbranchmanagerofbranch B is M_NEW valid from ${newManagerValidFrom}Andbranchmanager M_OLD managesemployee E until ${oldManagerValidUntil}Andbranchmanager M_NEW managesemployee E from ${newManagerValidFrom}And Evaluations for E1 still havethe same content| *Test* | *ClosedPeriod* | *Open Period* | *Run Import On* | *Old Manager Stops* | *New Manager Starts* || 1 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 11.11.2009 | 30.11.2009 | 1.12.2009 || 2 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.11.2009 | 31.10.2009 | 1.11.2009 || 3 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.12.2009 | 30.11.2009 | 1.12.2009 |

11. Performance is Non-Functional!All Non Functional Requirements are not very agileThey cannot be added later onSo you need to know about them!They form the Definition of Done

12. Testing Non-Functional is hard!There are no absolute measuresNo production infrastructure

13. How Do You Measure Performance?Relevant Measures are hard to findResponse TimeFor usersSystem LoadFor planningTrafficFor moneyRealistic Measures are hard to obtain2 seconds?Load avg < 2.8 ?Less than 2TB per month?

14. How Do You Test Performance?Who ...... has a process for performance tests?... does loadtests?... plans for scalability?... uses a profiler?... uses a server monitor?... uses an application monitor?

15. „ProductionisFaster“

16. Ensuring great PerformanceChapter Two:

17. A Typical Performance Analysis ProcessTom, the boss calls:“We loose customers because of bad performance”Lynn from QA does a load test:“Application is slow as a snail”Task force is set upJohn tries to learn performance toolsSarah does a microbenchmark and gains 5 ms Application still slow Everybody unhappy

18. How about…Developers care about performanceGood tools are understood and usedPerformance is tested regularlyAnomalies are taken care of Application is running smoothly Everybody is happy

19. Care About PerformanceCaring is fundamentally importantDevelopment teams need to extend their scopeIn Scrum teams need to be able to do all the work to get done

20. Good ToolsTool paralysis does not helpChoose 1 or 2 good tools and learn themTools should work everywhereflickr.com/photos/pmtorrone/2381346935

21. Continuously Test PerformanceFind a good balanceAutomated ChecksManual TestsFunctional tests already provide dataHow about a load test every iteration?

22. Investigate Suspicious DataBecause you careAnd you have the toolsAnd you have the dataYou should investigate findings“When you have eliminated the impossible,whatever remains, however improbable,must be the truth” - Sherlock Holmesflickr.com/photos/cayusa/2159980025

23. A real World ExampleChapter Three

24. Team Cares About PerformanceDefinition of Done includes a lotspec, design, unit test, code, acceptance tests, documentation, usability review, code review, stability tests, compatibility tests, interoperability test, load tests, security tests, performance tests…Get it right from the beginningDo not pile up technical debtTo go well you have to go slow

25. 20% Slowdown due to debt

26. Sprint 1

27. 15 Points delivered

28. Sprint 2

29. 12 Points delivered

30. Sprint 3

31. 9 Points delivered

32. Sprint 4

33. 7 Points deliveredTechnical Debt / Undone WorkWrong Definition of DoneBetter Definition of DoneSprint 1

34. 12 Points delivered

35. Sprint 2

36. 12 Points delivered

37. Sprint 3

38. 12 Points delivered

39. Sprint 4