need forbuildspeed agile2012
DESCRIPTION
TRANSCRIPT
© Reaktor 2012
The Need for(Build) Speed
Lasse Koskela
(Please go ahead and pre-fill those feedback forms. I appreciate that. It also
brings you that much closer to beer.)
© Reaktor 2012
Lasse Koskela works as a coach, trainer, consultant and programmer, spending his days helping clients and colleagues at Reaktor create successful software products.
Follow him on Twitter as @lassekoskela
”© Reaktor 2012
Standing between an audience and their beer is tough so you better talk fast.
~ agile conference proverb
Session Outline1) Impact of build time2) Profiling a build3) Optimizing test code4) Tweaking infrastructure
© Reaktor 2012
Impact of build time
© Reaktor 2012
Delayed feedback is bad for you• The faster you know that your software is
(still) working as it should the faster your brain can move on to the next thing.
• The longer you have to wait for feedback the higher the chance of doing rework and context-switching.
”© Reaktor 2012
http://gojko.net/2009/12/07/improving-testing-practices-at-google/
Delayed feedback costs $$$
[Google] estimated that a bug found during TDD costs $5 to fix, which surges to $50 for tests during a full build and $500 during an integration test. It goes to $5000 during a system test. Fixing bugs earlier would save them an estimated $160M per year.
© Reaktor 2012
Profiling a build
© Reaktor 2012
How do we know what’s up?• Shooting in the dark works amazingly well
...if you’re lucky.• The rest of us need to understand what is
making our build slow before reaching for our guns.
© Reaktor 2012
What exactly do we want to know?• How much time it takes altogether?• Which build activities take up the majority
of that total?• Which of these have potential for
optimization?
© Reaktor 2012
Demo
Profiling an Apache Ant build with built-in utilities and open source tools
© Reaktor 2012
Demo
Profiling an Apache Ant build with built-in utilities and open source tools
$ ant -listener net.sf.antcontrib.perf.AntPerformanceListener
© Reaktor 2012
Demo
Profiling an Apache Ant build with built-in utilities and open source tools
$ ant -listener net.sf.antcontrib.perf.AntPerformanceListener
$ ant -logger org.apache.tools.ant.listener.ProfileLogger
© Reaktor 2012
Demo
Profiling an Apache Maven build with built-in utilities and open source tools
© Reaktor 2012
Demo
Profiling an Apache Maven build with built-in utilities and open source tools
<build> <extensions> <extension> <groupId>com.github.lkoskela</groupId> <artifactId>maven-build-utils</artifactId> <version>1.4</version> </extension> </extensions> </build>
© Reaktor 2012
Optimizing test code
© Reaktor 2012
Tests can be slow because they...
© Reaktor 2012
Tests can be slow because they...
do many things.
a)
© Reaktor 2012
Tests can be slow because they...
do many things.
a)
do slow things.
b)
© Reaktor 2012
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
Examples ofslow things
Tests invoke Thread.sleep(...) to wait for task completion.
Components talk to each other over a network protocol.
Tests run against a production-like database.
Tests access afile system.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
Examples ofslow things
Tests invoke Thread.sleep(...) to wait for task completion.
Components talk to each other over a network protocol.
Tests run against a production-like database.
Tests access afile system.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
Examples ofslow things
Tests invoke Thread.sleep(...) to wait for task completion.
Components talk to each other over a network protocol.
Tests run against a production-like database.
Tests access afile system.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
Examples ofslow things
Tests invoke Thread.sleep(...) to wait for task completion.
Components talk to each other over a network protocol.
Tests run against a production-like database.
Tests access afile system.
© Reaktor 2012
Examples ofdoing too much
Tests do setup that isn’t relevant to the test.
Tests build input from unnecessarily raw materials.
Tests do the same thing many times when once is enough.
Tests use a slow real object when a stub would suffice.
Examples ofslow things
Tests invoke Thread.sleep(...) to wait for task completion.
Components talk to each other over a network protocol.
Tests run against a production-like database.
Tests access afile system.
© Reaktor 2012
Demo
An example of irrelevant setup that’s inherited through a hierarchy of abstract test classes.
© Reaktor 2012
Demo
An example of tests wasting valuable time by Thread#sleep’ing too much.
© Reaktor 2012
Demo
An example of a test that uses a slow(ish) real implementation that talks to the network stack.
© Reaktor 2012
Tweaking infrastructure
© Reaktor 2012
Is your build’s bottleneck...
I/OCPU
© Reaktor 2012
© Reaktor 2012
Peaking “user time” suggests CPU running hot
© Reaktor 2012
© Reaktor 2012
Peaking “idle time” suggests CPU is waiting
© Reaktor 2012
© Reaktor 2012
Peaking “system calls” suggests lots of I/O
© Reaktor 2012
Lifting the CPU bottleneckby using more hardware
© Reaktor 2012
Lifting the CPU bottleneckby using more hardware
© Reaktor 2012
Demo
An example of a Maven build that employs multiple CPU cores.
© Reaktor 2012
Lifting the CPU bottleneckby using better hardware
© Reaktor 2012
Lifting the CPU bottleneckby using better hardware
© Reaktor 2012
Lifting the CPU bottleneckby using better hardware
Amazon EC2 Small Instance1.7 GB memory1 virtual core with 1 EC2 compute units
Amazon EC2 Medium Instance3.75 GB memory1 virtual core with 2 EC2 compute units
© Reaktor 2012
Demo
An example of a Maven build that is run in the cloud on a (more or less) powerful computer.
© Reaktor 2012
Lifting the I/O bottleneckby using better hardware
© Reaktor 2012
Lifting the I/O bottleneckby using better hardware
© Reaktor 2012
Demo
An example of a build that is run from a (more or less) fast disk.
© Reaktor 2012
Lifting the I/O bottleneckby using more hardware
© Reaktor 2012
Lifting the I/O bottleneckby using more hardware
© Reaktor 2012
Summary
© Reaktor 2012
Please, fill thefeedback form for me.
I’d really appreciate that.TITLE: The Need for (Build) SpeedPRESENTER: Lasse Koskela