How to Manage Performance Engineering in Agile Projects: - New Challenges in Web 2.0 Applications - Performance Space in Agile Process - Performance Engineering Activities - A Case-study

1. Managing
Performance Engineering in
Agile Projects
STC 2011
Pramod Waghmode
Dr. Asheesh Choksi

2. Abstract
 Web 2.0 New Challenges
 Performance Space in Agile Process
 Traditional Performance Engineering Activities
 Performance Engineering Activities in Agile
 Exploring Opportunities
 Performance Measurements
 Findings and Recommendations
 Conclusions
STC 2011 2
2

3. New Challenges in Web 2.0 Applications
 Requirement
Provide improved user experience
 Rich and interactive UI elements
 Social interactivity: publish and share contents, events
 Pull contents from several portals to provide customized pages
 Using third party controls and libraries for quick implementation
STC 2011 3
3

4. Performance Space in Agile Process
Development Characteristics
 Short development Cycles
 Focused on Product Backlog
Performance Engineering Challenge
 User stories are not available to set
the Performance goals for sprints
No Check leads to Poor Quality Artifacts
 Hawthorne Effect*
 The Broken Window theory**
* http://en.wikipedia.org/wiki/Hawthorne_effect
STC 2011 ** http://www.codinghorror.com/blog/2005/06/the-broken-window-theory.html
4

5. Performance Engineering Activities
STC 2011 http://msdn.microsoft.com/en-us/library/bb924359.aspx 5
5

6. Performance Engineering Activities in Agile
STC 2011 6
6

7. Exploring Opportunities
 Optimization Opportunities
 Minify JavaScript
 Cache static resources, set appropriate expiry
 Compress datasets (XML, JSON). This needs extra CPU cycles.
 Configure Etags
 Baseline component performance
 Check the response time, throughput, latency with different loads
 Check DB related requests for their responses
 Monitor CPU, memory, connection pool, disk I/O
 Find result set paging opportunities
 Identify requests to third party components/servers
STC 2011 7
7

8. Case Study
STC 2011
8

9. Load Plan
 Total number of Virtual users: 20
 Number of Virtual users per batch: 20
 Batch Ramp up time: 10 min
 Think time: Normal Distribution Pattern [Application specific
parameters]
 Number of Iterations: 15
STC 2011 9
9

10. Page Response vs. User Load Time
 CPU: 2.66
GHz dual
core
 RAM: 2 GB
 Windows
2K3 server
STC 2011 10
10

11. Web Processor Utilization vs. User Load
 CPU: 2.66
GHz dual
core
 RAM: 2 GB
 Windows
2K3 server
STC 2011 11
11

12. W3wp – Private Bytes vs. User Load
 CPU: 2.66
GHz dual
core
 RAM: 2 GB
 Windows
2K3 server
STC 2011 12
12

13. Findings and Recommendations
 The application appeared to be non scalable as the response time
increases linearly with user load
 It was found that there were some un-optimized queries
 Memory leaks were detected in a particular library
 Further code profiling was recommended
 Memory Dump Analysis revealed high frequency of GC.
 It was observed that large size objects were getting disposed. This is
being optimized.
STC 2011 13
13

14. Conclusions
 Performance Testing process in Agile Methodology brings in a change
in “Attitude of team”
 Though there are no clear performance goals in a given sprint, the
system bottlenecks are constantly checked
 The issues are known and fixed much earlier in the dev cycle
 This results in a robust application as the application is benchmarked
across its different features
 The benchmark data provides crisp pointers for capacity planning
 However, this does not do away the need for Load testing on
Realistic Production Environment.
STC 2011 14
14

15. Thank You!
rfi@harbingergroup.com
www.harbinger-systems.com
STC 2011
15