Load Testing Best Practices

Why Load Test?

Performance MattersOrganizations 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%

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.

Application complexity is Increasing

THEN

Application Complexity is IncreasingNOW

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?

What kind of load test should you use?

Load Test Types

Stress Concurrency

Disaster Recovery

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)

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

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

Recording load test scripts

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.

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?

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.

Questions to Ask When Recording Scripts

What constitutes a failure?• Content verification• HTTP Status checks• General or request specific time limits• Unusual response sizes

Steps to Recording Scripts1. Determine the user flow2. Record using a proxy recorder3. Remove unnecessary requests4. Handle variables5. Add external data6. Configure failure detection

Running Load Tests

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

Interpreting Results

What Does It Mean? (Load Curves)

USERSSESS

ION

DU

RATI

ON

USERSTH

ROU

GH

PUT

USERSFAIL

URE

S / E

RRO

RS

Ideal Results

What Does It Mean? (Load Curves)

USERSSESS

ION

DU

RATI

ON

USERSTH

ROU

GH

PUT

USERSFAIL

URE

S / E

RRO

RS

Finding Peak Load

SAFE PEAK UNSTABLE

When to Load Test

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)

Questions?

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