• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Development of High Performance Applications

Agile Development of High Performance Applications



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:

If you want to try appdynamics lite yourself, download it at http://appdynamics.com/free



Total Views
Views on SlideShare
Embed Views



1 Embed 30

http://blog.codecentric.de 30



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Agile Development of High Performance Applications Agile Development of High Performance Applications Presentation Transcript

    • Monitoring Performance from Development through Production
      Agile Development of HIGH Performance APPLICATIONS
    • Fabian Lange
      Head of Competence Center Performance
      Java since its beginning
      Agile since its establishment
      Performance since waiting got boring
      • codecentric AG
      • Specialized in
      • Perfomance Services
      • Agile Software Factory
      • 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"
    • The curse of non-functional Requirements
      Chapter One
    • Who measures performance …
      in production?
      before production?
      during development?
      Who does development …
      the waterfall way?
      the agile way?
      Let‘s Do a Poll
    • We finally can test functional requirements!
      Many modern practices
      Testing Requirements
    • Executable Specifications makes functional testing a breeze!
      *** 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}
      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 |
    • 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
    • Testing Non-Functional is hard!
      There are no absolute measures
      No production infrastructure
    • How Do You Measure Performance?
      Relevant Measures are hard to find
      Response Time
      For users
      System Load
      For planning
      For money
      Realistic Measures are hard to obtain
      2 seconds?
      Load avg < 2.8 ?
      Less than 2TB per month?
    • 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?
    • „ProductionisFaster“
    • Ensuring great Performance
      Chapter Two:
    • 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
    • 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
    • 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
    • Good Tools
      Tool paralysis does not help
      Choose 1 or 2 good tools and learn them
      Tools should work everywhere
    • Continuously Test Performance
      Find a good balance
      Automated Checks
      Manual Tests
      Functional tests already provide data
      How about a load test every iteration?
    • 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
    • A real World Example
      Chapter Three
    • 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
      • 20% Slowdown due to debt
      • Sprint 1
      • 15 Points delivered
      • Sprint 2
      • 12 Points delivered
      • Sprint 3
      • 9 Points delivered
      • Sprint 4
      • 7 Points delivered
      Technical Debt / Undone Work
      Wrong Definition of Done
      Better Definition of Done
      • Sprint 1
      • 12 Points delivered
      • Sprint 2
      • 12 Points delivered
      • Sprint 3
      • 12 Points delivered
      • Sprint 4
      • 12 Points delivered
    • WHAT MAKES A Great Tool
      Zero configuration a must for agile
      Very low overhead for clean results
      Single tool for all use cases
    • AppDynamicsLite Demo
      Webcasts in our bloghttp://blog.codecentric.de/en/2010/08/easy-performance-analysis-with-appdynamics-lite/
    • Automated Work
      Monitoring is not only great for production
      Runs in Continuous Integration environments
      Uses automated tests to run
      Provides Trends during iterations
    • 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 Report
      • [Run a debugger]
      • Fix it
      • Business Transaction Overview
      • Call Graph
      • [Run a profiler]
      • Fix it
    • A Junit Report
    • Daily Health Check
    • Spot On Answer
    • Find Ananomalies
    • InvestigatewithFull Call StackVisibility
    • All The Data You Need
    • Manual Work
      Manual load and scalability tests once an iteration
      Requires close to production configuration
    • Basic LoadTesting
    • The DevOps Revolution
      Chapter Four
    • 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
    • DevOpsand Performance
      In the cloud, the only real test is production
      Avoid premature optimization
      Requires great tools
    • High Performance Apps Go Live Every Day
    • 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