Slides from my talk at gearconf 2010 in Düsseldorf, discussing Performance as an important non-functional requirement. Because NFRs are hard to test, I showed how AppDynamics Lite could be used to ease pain and build better performing apps. If you are interested in performance and application performance monitoring, visit our blog: http://blog.codecentric.de/en/category/performance-en/ If you want to try appdynamics lite yourself, download it at http://appdynamics.com/free

1. Monitoring Performance from Development through Production Agile Development of HIGH Performance APPLICATIONS

3. Specialized in

4. Perfomance Services

5. Agile Software Factory

7. The curse of non-functional Requirements Chapter 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 practices TDD ATDD BDD Testing Requirements

10. Executable Specifications makes functional testing a breeze! RequirementsaretheTEst *** Settings *** Resource ${RESOURCES}/BDD.txt Test Template Branch Manager Change Should not affectEmployee *** Keyword *** Branch Manager Change Should not affectEmployee [Arguments] ${periodClosed} ${periodOpenAndModified} ${importDay} ${oldManagerValidUntil} ${newManagerValidFrom} Giveninitializedcriteriaforbonuscommercial And a branch B withbranchmanager M_OLD andemployee E1 Andevaluationfor E1 forperiod ${periodClosed} whichisclosed Andevaluationfor E1 forperiod ${periodOpenAndModified} whichis open andmodified When M_NEW becomesnewmanagerofbranch B Andimportserviceiscalled 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 agile They cannot be added later on So you need to know about them! They form the Definition of Done

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

13. How Do You Measure Performance? Relevant Measures are hard to find Response Time For users System Load For planning Traffic For money Realistic Measures are hard to obtain 2 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 Performance Chapter Two:

17. A Typical Performance Analysis Process Tom, 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 up John tries to learn performance tools Sarah does a microbenchmark and gains 5 ms  Application still slow  Everybody unhappy

18. How about… Developers care about performance Good tools are understood and used Performance is tested regularly Anomalies are taken care of  Application is running smoothly  Everybody is happy

19. Care About Performance Caring is fundamentally important Development teams need to extend their scope In Scrum teams need to be able to do all the work to get done

20. Good Tools Tool paralysis does not help Choose 1 or 2 good tools and learn them Tools should work everywhere flickr.com/photos/pmtorrone/2381346935

21. Continuously Test Performance Find a good balance Automated Checks Manual Tests Functional tests already provide data How about a load test every iteration?

22. Investigate Suspicious Data Because you care And you have the tools And you have the data You should investigate findings “When you have eliminated the impossible,whatever remains, however improbable,must be the truth” - Sherlock Holmes flickr.com/photos/cayusa/2159980025

23. A real World Example Chapter Three

24. Team Cares About Performance Definition of Done includes a lot spec, 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 beginning Do not pile up technical debt To go well you have to go slow

26. Sprint 1

27. 15 Points delivered

28. Sprint 2

29. 12 Points delivered

30. Sprint 3

31. 9 Points delivered

32. Sprint 4

34. 12 Points delivered

35. Sprint 2

36. 12 Points delivered

37. Sprint 3

38. 12 Points delivered

39. Sprint 4

40. 12 Points delivered11.10.2010 22

41. WHAT MAKES A Great Tool Zero configuration a must for agile Very low overhead for clean results Single tool for all use cases Free!

42. AppDynamicsLite Demo Webcasts in our bloghttp://blog.codecentric.de/en/2010/08/easy-performance-analysis-with-appdynamics-lite/

43. Automated Work Monitoring is not only great for production Runs in Continuous Integration environments Uses automated tests to run Provides Trends during iterations

45. [Run a debugger]

46. Fix it

47. Business Transaction Overview

48. Call Graph

49. [Run a profiler]

50. Fix it11.10.2010 26

51. A Junit Report

52. Daily Health Check

53. Spot On Answer

54. Find Ananomalies

55. InvestigatewithFull Call StackVisibility

56. All The Data You Need

57. Manual Work Manual load and scalability tests once an iteration Requires close to production configuration

58. Basic LoadTesting

59. The DevOps Revolution Chapter Four

60. DevOpsthinks different Agile process provides high quality Test environments are slow, and often not real Done features go to production every day Use real users for testing Planned rollbacks integral part commons.wikimedia.org/wiki/File:Beta-badge.svg

61. DevOpsand Performance In the cloud, the only real test is production Avoid premature optimization Requires great tools flickr.com/photos/design-dog/1249337589

62. High Performance Apps Go Live Every Day Epilogue

63. Non-Functional Requirements are known and taken care of Performance is monitored in development Anomalies are taken care of Pre-Release sanity check is performed Up- and Downgrade is planned New version can go into production Productive software is examined around the clock Summary flickr.com/photos/redux/4740529728