Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile performance testing

Agile performance testing

Agile performance testing with Amazon AWS, tmux and siege

Andreas Bjärlestam

March 30, 2016
Tweet

More Decks by Andreas Bjärlestam

Other Decks in Programming

Transcript

  1. Understanding your system Andreas Bjärlestam! 2016-03-30! _____ .__.__ / _

    \ ____ |__| | ____ / /_\ \ / ___\| | | _/ __ \ / | \/ /_/ > | |_\ ___/ \____|__ /\___ /|__|____/\___ > \//_____/ \/ _____ ______ ____________/ ____\___________ _____ _____ ____ ____ ____ \____ \_/ __ \_ __ \ __\/ _ \_ __ \/ \\__ \ / \_/ ___\/ __ \ | |_> > ___/| | \/| | ( <_> ) | \/ Y Y \/ __ \| | \ \__\ ___/ | __/ \___ >__| |__| \____/|__| |__|_| (____ /___| /\___ >___ > |__| \/ \/ \/ \/ \/ \/ __ __ .__ _/ |_ ____ _______/ |_|__| ____ ____ \ __\/ __ \ / ___/\ __\ |/ \ / ___\ | | \ ___/ \___ \ | | | | | \/ /_/ > |__| \___ >____ > |__| |__|___| /\___ / \/ \/ \//_____/
  2. Do you know on top of your head: •  How

    many req/s your system can handle? •  What response >me it has? •  How it scales? •  What the bo@lenecks are? •  How stable it is over >me?
  3. Stop seeing performance tests as verifica>on It should be an

    integrated part of your development cycle Con>nuously analyze your system
  4. siege •  Quick and simple •  Instant visual feedback • 

    Good summary of most important metrics •  Good enough for most scenarios = You can work in quick itera>ons
  5. When replacing a system Get access logs from the old

    system Analyze which parts of the system that generate the most load Plot them over >me to get a feeling for peaks and average load
  6. If you replay access logs against your system with siege

    you can gain a lot of insights and find problems like unhandled urls, unnecessary redirects etc
  7. Build a urls.txt file Based on traffic model Fill a

    file with urls that represent your expected traffic, one url per line Think about the propor>ons of different types of urls
  8. Build a urls.txt file Expec>ng broad traffic -> many urls

    Expec>ng narrow traffic -> not so many
  9. Build a urls.txt file You can send POST as well

    h@p://example.com/user/s>na POST age=23 h@p://example.com/user/s>na POST a=1&b=2 h@p://example.com/user/s>na POST <./s>na.txt
  10. This is a good >me to think about the bo@lenecks

    of your system I/O CPU Sync / Async
  11. Start a linux machine on AWS Set up a session

    with tmux Start siege Leave it running
  12. Put your system under con>nuous load from your first commit

    Keep an eye on system metrics every now and then
  13. Good to know: siege counts error responses and will stop

    if it encounters more than 1024 errors
  14. TLDR Stop doing performance tests like its 1999 Put your

    system under load from day 1 Run tests interac>vely, be crea>ve Gain understanding AWS + tmux + siege is awesome!
  15. tmux cheat sheet > tmux new -s loadtest starts a

    new session named loadtest ctrl-b + d exits session > tmux list-sessions lists all current sessions > tmux a@ach -t loadtest a@aches to the session named loadtest
  16. If siege does not fit your use case You could

    try - gatling - locust - wrk They are bigger (more complex) hammers