Load Testing Best Practices: Application complexity is increasing, yet the stringent requirements for web performance is increasing exponentially. Learn more about the three major types of load testing, determine which you need and how to conduct them.
3. Performance Matters
Organizations with degraded business apps (IDG)
Problems identified for IT by end-users (EMA)
- employees – 43%
- business stakeholders – 13%
- customers – 12%
Problems resolved > 1 month, if ever (Forrester)
Engineering time spent in triage (TechValidate)
75%
68%
31%
40%
4. Unit and Functional Tests Don’t Find Everything
• Concurrency Bugs
– Bugs that only present when same code is run multiple times at the same time
• Compositional Bugs
– Bugs caused by the interplay between separate pieces of your application
• DB Indexes and Locks
– Do the indexes and query locks on your database play nicely at load
• Application or Web Server Configuration
– Do your application or web servers exceed memory, socket, or other configuration
constraints
• Infrastructure Limitations
– Bandwidth, Session Tables, Disk IO, Etc.
8. Can You Answer These Basic Questions?
• What are your application’s bottlenecks?
• Performance at normal and peak usage
levels?
• Most common causes of
performance issues or load based
failures?
• Is your hardware optimized to meet business
objectives?
11. Stress Tests
Continuously increase load to determine
absolute theoretical bottlenecks and
breaking points
• Start with known good traffic levels
• Run successive tests while doubling the traffic each time
• When breaking point is found, you can run tests between the last
successful test and this one to find your exact breaking point(s)
12. Concurrency Tests
Realistic traffic to find practical performance
and failure limits
• Determine your actual traffic levels (average and peak), and the ratio
of user flows/actions
• Run a combination of load tests that simulate realistic traffic
• Perform “what if” tests by either changing the mix of user
flows/actions, or increasing the load of one or more of them
• Concurrency Tests against auto-scaling environments can test
scaling response times
13. Disaster Recovery Tests
Sustained traffic at realistic load levels to
test application response to failures
• Start a long-running load test
• Simulate various application or infrastructure failures (e.g. turn off a
web server, or unplug a DB)
• See if failover processes work as intended, and as fast as required
• DR tests without simulated failures are ENDURANCE tests
15. Questions to Ask When Recording Scripts
What do you want to know?
• Max concurrent users before failure
• Performance at expected peak
• 3rd party content impact on performance
• Current bottlenecks
• Auto-scaling results at various loads
• Etc.
16. Questions to Ask When Recording Scripts
What requests matter?
• Do you care about static/CDN served content?
• Do you need to include 3rd party content?
• Do supporting requests (e.g. auto-populate) matter?
17. Questions to Ask When Recording Scripts
Do you need unique or dynamic data?
• Usernames and passwords
• Form data (e.g. dates)
• Product or record ID’s
• Etc.
18. Questions to Ask When Recording Scripts
What constitutes a failure?
• Content verification
• HTTP Status checks
• General or request specific time limits
• Unusual response sizes
19. Steps to Recording Scripts
1. Determine the user flow
2. Record using a proxy recorder
3. Remove unnecessary requests
4. Handle variables
5. Add external data
6. Configure failure detection
26. Load Testing @ Deployment Stages
• Dev Environments
– Good for finding problems early, but unreliable for absolute performance metrics
– Catch concurrency, composition, or DB problems
• Staging/QA Environments
– Catch problems caused by rolled up commits that weren’t visible when testing singular changes
– Compare to previous runs to get early warnings for reduced performance or peak capacity
– May or may not be reliable indicators of production performance depending on the stability of the
environment, and similarity to the production environment
• Pre-Production
– Should be as close to the production environment as possible
– Best indication of production performance and load capacity before live deployment
• Production
– Useful for absolute verification of readiness for expected traffic spikes (e.g. product launces, sales,
holidays, marketing events)
– Can be used for periodic validations (DR, seamless code deployment, performance validation)