Agile Development of High Performance Applications

3,817 views

Published on

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

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,817
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
82
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Agile Development of High Performance Applications

  1. Monitoring Performance from Development through Production<br />Agile Development of HIGH Performance APPLICATIONS<br />
  2. Fabian Lange<br />Head of Competence Center Performance<br />Java since its beginning<br />Agile since its establishment<br />Performance since waiting got boring<br />Meandcodecentric<br /><ul><li>codecentric AG
  3. Specialized in
  4. Perfomance Services
  5. Agile Software Factory
  6. Alwayslookingfornewtalent</li></li></ul><li>Table of Contents<br />Chapter One"The curse of non-functional Requirements”<br />Chapter Two“Ensuring Great Performance”<br />Chapter Three“A Real World Example”<br />Chapter Four“The DevOps Revolution"<br />Epilogue<br />
  7. The curse of non-functional Requirements<br />Chapter One<br />
  8. Who measures performance …<br />in production?<br />before production?<br />during development?<br />Who does development …<br />the waterfall way?<br />the agile way?<br />Let‘s Do a Poll<br />
  9. We finally can test functional requirements!<br />Many modern practices<br />TDD<br />ATDD<br />BDD<br />Testing Requirements<br />
  10. Executable Specifications makes functional testing a breeze!<br />RequirementsaretheTEst<br />*** Settings ***<br />Resource ${RESOURCES}/BDD.txt<br />Test Template Branch Manager Change Should not affectEmployee<br />*** Keyword ***<br />Branch Manager Change Should not affectEmployee<br /> [Arguments] ${periodClosed} ${periodOpenAndModified} ${importDay} ${oldManagerValidUntil} ${newManagerValidFrom}<br />Giveninitializedcriteriaforbonuscommercial<br />And a branch B withbranchmanager M_OLD andemployee E1<br />Andevaluationfor E1 forperiod ${periodClosed} whichisclosed<br />Andevaluationfor E1 forperiod ${periodOpenAndModified} whichis open andmodified<br />When M_NEW becomesnewmanagerofbranch B<br />Andimportserviceiscalled on ${importDay}<br />Thenthenewbranchmanagerofbranch B is M_NEW valid from ${newManagerValidFrom}<br />Andbranchmanager M_OLD managesemployee E until ${oldManagerValidUntil}<br />Andbranchmanager M_NEW managesemployee E from ${newManagerValidFrom}<br />And Evaluations for E1 still havethe same content<br />| *Test* | *ClosedPeriod* | *Open Period* | *Run Import On* | *Old Manager Stops* | *New Manager Starts* |<br />| 1 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 11.11.2009 | 30.11.2009 | 1.12.2009 |<br />| 2 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.11.2009 | 31.10.2009 | 1.11.2009 |<br />| 3 | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.12.2009 | 30.11.2009 | 1.12.2009 |<br />
  11. Performance is Non-Functional!<br />All Non Functional Requirements are not very agile<br />They cannot be added later on<br />So you need to know about them!<br />They form the Definition of Done<br />
  12. Testing Non-Functional is hard!<br />There are no absolute measures<br />No production infrastructure<br />
  13. How Do You Measure Performance?<br />Relevant Measures are hard to find<br />Response Time<br />For users<br />System Load<br />For planning<br />Traffic<br />For money<br />Realistic Measures are hard to obtain<br />2 seconds?<br />Load avg < 2.8 ?<br />Less than 2TB per month?<br />
  14. How Do You Test Performance?<br />Who ...<br />... has a process for performance tests?<br />... does loadtests?<br />... plans for scalability?<br />... uses a profiler?<br />... uses a server monitor?<br />... uses an application monitor?<br />
  15. „ProductionisFaster“<br />
  16. Ensuring great Performance<br />Chapter Two:<br />
  17. A Typical Performance Analysis Process<br />Tom, the boss calls:“We loose customers because of bad performance”<br />Lynn from QA does a load test:“Application is slow as a snail”<br />Task force is set up<br />John tries to learn performance tools<br />Sarah does a microbenchmark and gains 5 ms<br /> Application still slow<br /> Everybody unhappy<br />
  18. How about…<br />Developers care about performance<br />Good tools are understood and used<br />Performance is tested regularly<br />Anomalies are taken care of<br /> Application is running smoothly<br /> Everybody is happy<br />
  19. Care About Performance<br />Caring is fundamentally important<br />Development teams need to extend their scope<br />In Scrum teams need to be able to do all the work to get done<br />
  20. Good Tools<br />Tool paralysis does not help<br />Choose 1 or 2 good tools and learn them<br />Tools should work everywhere<br />flickr.com/photos/pmtorrone/2381346935<br />
  21. Continuously Test Performance<br />Find a good balance<br />Automated Checks<br />Manual Tests<br />Functional tests already provide data<br />How about a load test every iteration?<br />
  22. Investigate Suspicious Data<br />Because you care<br />And you have the tools<br />And you have the data<br />You should investigate findings<br />“When you have eliminated the impossible,whatever remains, however improbable,must be the truth” - Sherlock Holmes<br />flickr.com/photos/cayusa/2159980025<br />
  23. A real World Example<br />Chapter Three<br />
  24. Team Cares About Performance<br />Definition of Done includes a lot<br />spec, design, unit test, code, acceptance tests, documentation, usability review, code review, stability tests, compatibility tests, interoperability test, load tests, security tests, performance tests…<br />Get it right from the beginning<br />Do not pile up technical debt<br />To go well you have to go slow<br />
  25. <ul><li>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 delivered</li></ul>Technical Debt / Undone Work<br />Wrong Definition of Done<br />Better Definition of Done<br /><ul><li>Sprint 1
  34. 12 Points delivered
  35. Sprint 2
  36. 12 Points delivered
  37. Sprint 3
  38. 12 Points delivered
  39. Sprint 4
  40. 12 Points delivered</li></ul>11.10.2010<br />22<br />
  41. WHAT MAKES A Great Tool<br />Zero configuration a must for agile<br />Very low overhead for clean results<br />Single tool for all use cases<br />Free!<br />
  42. AppDynamicsLite Demo<br />Webcasts in our bloghttp://blog.codecentric.de/en/2010/08/easy-performance-analysis-with-appdynamics-lite/<br />
  43. Automated Work<br />Monitoring is not only great for production<br />Runs in Continuous Integration environments<br />Uses automated tests to run<br />Provides Trends during iterations<br />
  44. Continuous Integration Tools show where to look<br />Usually already providing information about where to look<br />Sometimes providing information about how to fix<br />Easy Investigation<br />JUnit<br />AppDynamics<br /><ul><li>JUnit Report
  45. [Run a debugger]
  46. Fix it
  47. Business Transaction Overview
  48. Call Graph
  49. [Run a profiler]
  50. Fix it</li></ul>11.10.2010<br />26<br />
  51. A Junit Report<br />
  52. Daily Health Check<br />
  53. Spot On Answer<br />
  54. Find Ananomalies<br />
  55. InvestigatewithFull Call StackVisibility<br />
  56. All The Data You Need<br />
  57. Manual Work<br />Manual load and scalability tests once an iteration<br />Requires close to production configuration<br />
  58. Basic LoadTesting<br />
  59. The DevOps Revolution<br />Chapter Four<br />
  60. DevOpsthinks different<br />Agile process provides high quality<br />Test environments are slow, and often not real<br />Done features go to production every day<br />Use real users for testing<br />Planned rollbacks integral part<br />commons.wikimedia.org/wiki/File:Beta-badge.svg<br />
  61. DevOpsand Performance<br />In the cloud, the only real test is production<br />Avoid premature optimization<br />Requires great tools<br />flickr.com/photos/design-dog/1249337589<br />
  62. High Performance Apps Go Live Every Day<br />Epilogue<br />
  63. Non-Functional Requirements are known and taken care of<br />Performance is monitored in development<br />Anomalies are taken care of<br />Pre-Release sanity check is performed<br />Up- and Downgrade is planned<br />New version can go into production<br />Productive software is examined around the clock<br />Summary<br />flickr.com/photos/redux/4740529728<br />

×