Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Agile performance testing
Search
Andreas Bjärlestam
March 30, 2016
Programming
0
110
Agile performance testing
Agile performance testing with Amazon AWS, tmux and siege
Andreas Bjärlestam
March 30, 2016
Tweet
Share
More Decks by Andreas Bjärlestam
See All by Andreas Bjärlestam
Climate compensate with a pull request
bjarlestam
0
31
SPDY and HTTP2
bjarlestam
1
1.2k
SPDY or maybe HTTP2.0
bjarlestam
4
62
jquery mobile
bjarlestam
0
69
Devise - taking care of your users
bjarlestam
0
71
REST with JAX-RS
bjarlestam
1
89
REST
bjarlestam
2
170
Other Decks in Programming
See All in Programming
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
2
21k
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
13k
MCPを使ってイベントソーシングのAIコーディングを効率化する / Streamlining Event Sourcing AI Coding with MCP
tomohisa
0
170
ふつうの技術スタックでアート作品を作ってみる
akira888
1
1.3k
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
99
37k
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
320
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
1k
Hack Claude Code with Claude Code
choplin
7
2.5k
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
220
Model Pollution
hschwentner
1
160
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
660
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
470
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Being A Developer After 40
akosma
90
590k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Transcript
Understanding your system Andreas Bjärlestam! 2016-03-30! _____ .__.__ / _
\ ____ |__| | ____ / /_\ \ / ___\| | | _/ __ \ / | \/ /_/ > | |_\ ___/ \____|__ /\___ /|__|____/\___ > \//_____/ \/ _____ ______ ____________/ ____\___________ _____ _____ ____ ____ ____ \____ \_/ __ \_ __ \ __\/ _ \_ __ \/ \\__ \ / \_/ ___\/ __ \ | |_> > ___/| | \/| | ( <_> ) | \/ Y Y \/ __ \| | \ \__\ ___/ | __/ \___ >__| |__| \____/|__| |__|_| (____ /___| /\___ >___ > |__| \/ \/ \/ \/ \/ \/ __ __ .__ _/ |_ ____ _______/ |_|__| ____ ____ \ __\/ __ \ / ___/\ __\ |/ \ / ___\ | | \ ___/ \___ \ | | | | | \/ /_/ > |__| \___ >____ > |__| |__|___| /\___ / \/ \/ \//_____/
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?
Many s>ll do big bang performance tes>ng
Stop seeing performance tests as verifica>on It should be an
integrated part of your development cycle Con>nuously analyze your system
You should do it all the >me!
I’m lazy, so performance tes>ng must be quick and simple
isola>on
Your test client should do nothing but loadtes>ng, no interference
Amazon AWS + tmux = win!
You can leave it on and come back to check
every now and then
Combine with monitoring: Newrelic Kibana Graphite
> sudo yum install siege
> siege -c10 -t30s -d1 -i -f urls.txt
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
Create a Traffic Model
Your best guess of how the system will be used
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
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
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
Build a urls.txt file Expec>ng broad traffic -> many urls
Expec>ng narrow traffic -> not so many
Build a urls.txt file h@p://example.com h@p://example.com/user/s>na h@p://example.com/user/olof h@p://example.com/user/sven h@p://example.com/user/siv h@p://example.com/user/ellen
h@p://example.com/country/sweden h@p://example.com/country/norway
Build a urls.txt file curl cut jq grep etc are
your friends
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
Finding the system limits
10 req/s OK 100 req/s OK 500 req/s Slooow 300
req/s OK
Scale up with more CPU or processors and try again
Does it scale linearly?
This is a good >me to think about the bo@lenecks
of your system I/O CPU Sync / Async
Adjust and try again
Keep an eye on system metrics Response >me CPU load
Memory usage Error rates etc
Stability tes>ng
Start a linux machine on AWS Set up a session
with tmux Start siege Leave it running
> siege -c10 -t24h -i -d1 -f urls.txt
Put your system under con>nuous load from your first commit
Keep an eye on system metrics every now and then
Good to know: siege counts error responses and will stop
if it encounters more than 1024 errors
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!
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
If siege does not fit your use case You could
try - gatling - locust - wrk They are bigger (more complex) hammers