Your SlideShare is downloading. ×
Agile Development of High Performance Applications
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

Agile Development of High Performance Applications

2,379
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 …

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
2,379
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
80
Comments
0
Likes
4
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

Transcript

  • 1. Monitoring Performance from Development through Production
    Agile Development of HIGH Performance APPLICATIONS
  • 2. Fabian Lange
    Head of Competence Center Performance
    Java since its beginning
    Agile since its establishment
    Performance since waiting got boring
    Meandcodecentric
    • codecentric AG
    • 3. Specialized in
    • 4. Perfomance Services
    • 5. Agile Software Factory
    • 6. Alwayslookingfornewtalent
  • Table of Contents
    Chapter 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 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
  • 25. Technical Debt / Undone Work
    Wrong Definition of Done
    Better Definition of Done
    11.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
  • 44. Continuous Integration Tools show where to look
    Usually already providing information about where to look
    Sometimes providing information about how to fix
    Easy Investigation
    JUnit
    AppDynamics
    11.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

×