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.

1. Load Testing Best Practices

2. Why Load Test?

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.

5. Application complexity is Increasing

6. THEN

7. Application Complexity is Increasing
NOW

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?

9. What kind of load test
should you use?

10. Load Test Types
Stress Concurrency Disaster Recovery

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

14. Recording load test
scripts

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

20. Running Load Tests

21. Considerations when running Load Tests
•SaaS vs Private
•Target Environment (Dev, DR, Prod)
•Other performance metrics (APM, etc.)
•Database preparation
•Team communication methods
•Criteria for aborting

22. Interpreting Results

23. What Does It Mean? (Load Curves)
USERS
SESSIONDURATION
USERS
THROUGHPUT
USERS
FAILURES/ERRORS
Ideal Results

24. What Does It Mean? (Load Curves)
USERS
SESSIONDURATION
USERS
THROUGHPUT
USERS
FAILURES/ERRORS
Finding Peak Load
SAFE PEAK UNSTABLE

25. When to Load Test

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)

27. Questions?

28. Additional Resources
apicasystems.com: Enterprise cloud and mobile performance solutions
- Whitepapers, Webinars, Case Studies
- Blog
- Download Apica Zebratester Free Edition | 50 Free VUs
- Signup for Apica LoadTest Free Trial | 500 Free VUs
- Signup for Apica Monitoring Free Trial
community.zebratester.com: Load test community