JavaLand 2016: Continuous performance

Continuous Performance
Load testing for developers with Gatling
Bert
Jan
Schrijver
@bjschrijverbertjan@jpoint.nl

@bjschrijver@bjschrijver
Bert Jan Schrijver
Let’s meet

Outline
• Performance testing process
• Introduction to Gatling
• Demo
• Results
• Looking forward
• Summary
• Q&A

How it all started…

Performance testing should be
part of the process

Performance testing traditionally…
…happens several times per year 
 
…and/or at major releases 
 
…is performed by specialists 
 
.. which is far from ideal: 
 
- changes were made long ago 
 
- many different code changes 
 
- at a certain moment in time 
 
- when is a test required?

Traditional performance testing
design
write code
test code
performance test
release
unit tests
integration tests

design
write code
test code
release
unit tests
integration tests
performance tests
Performance testing in  
continuous delivery

Continuous Delivery
Demands code to be
Always production ready
Short feedback cycles
Maintained by self-supporting 
teams
In regard to performance
Has to be under control
Effects should be clear ASAP
No external specialists

Part of the process
With the same level of support as 
- Unit-tests and integration tests 
- Continuous Integration 
- Zero-downtime deployments 
Performed by the development team

Performance testing process
Design Record Operationalise Execute Report

Designing scenarios
Generic tests used to test core functionality
Specialised tests used to test speciﬁc features

Tool support is key for
performance test adoption

Gatling
package computerdatabase // 1
import io.gatling.core.Predef._ // 2
import io.gatling.http.Predef._
import scala.concurrent.duration._
class BasicSimulation extends Simulation { // 3
val httpConf = http // 4
.baseURL("http://computer-database.gatling.io") // 5
.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8") // 6
.doNotTrackHeader("1")
.acceptLanguageHeader("en-US,en;q=0.5")
.acceptEncodingHeader("gzip, deflate")
.userAgentHeader("Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0")
val scn = scenario("BasicSimulation") // 7
.exec(http("request_1") // 8
.get("/")) // 9
.pause(5) // 10
setUp( // 11
scn.inject(atOnceUsers(1)) // 12
).protocols(httpConf) // 13
}

Alternative tools
And many more…

Gatling core concepts
Scenario
Feeder
A sequence of http requests used to simulate application usage
A tool used to fill request parameters
Recorder The tool used to record http requests or take a HAR-file  
and convert it to Gatling DSL
Gatling DSL Easy-to-read, developer-friendly way of defining tests

Scenario to outcome
Browser HAR-ﬁle
Gatling recorder DSL
Custom changes DSL
Gatling Report

Reports

Interpretations
We can 
See how changes affect performance 
Have feedback on performance in short amount of time 
 
We cannot 
See which load the application can endure in production

Results so far
- At least one time prevented issues in production
- Helped testing performance fixes and database tuning
- Discovered configuration error in test infrastructure
- Helped track down and validate a fix for a memory leak

- Automate (re-)recording process
- Re-use functional test scenarios as performance tests
- Eliminate custom code changes
Further development

Some take-aways
Performance testing should be a ﬁrst class citizen in your development cycle
Frontend changes can impact backend performance
Gatling is an awesome programmer friendly tool for load testing
The approach I shared monitors performance trends - it does NOT determine
the maximum load a production environment can endure
https://github.com/timve/continuous-performance-demo
https://github.com/bertjan/gatling-seed

Thanks for your time!
Please care about
conference quality.
Liked it? Tweet it!

JavaLand 2016: Continuous performance

More Related Content

Viewers also liked (8)

Similar to JavaLand 2016: Continuous performance (20)

JavaLand 2016: Continuous performance