The document discusses the complexities of software performance optimization, emphasizing it as both a craft and an art requiring creativity, research, and a business perspective. It highlights the consequences of poor performance, using examples like Amazon's sales drop due to delays, and stresses the importance of real performance testing in production environments. The text also identifies challenges in development and operations collaboration, the need for continuous performance testing, and the significance of adhering to best practices and tools to avoid common pitfalls.

1. A Challenging Craft

2. That‘s me
 My day to day job is to help customers
fixing software performance
Fabian
 People really struggle with performance
 But most of them struggle with coding as well
 If creating good software is a craft,
performance should be one as well
Customer

4.  Some say:
„creating software is art“
 Art and software development
need creativity
Art

5.  Fixing performance is
often considered magic
 Magic is something
 only you understand
 you do in a hard to
Magic
follow fashion

6.  Correctness in detail
 Research and verification
Craft

7.  All types share
 Passion
 Learning
 Experience
Which way?

11.  Value == Money
 We need a business case
for performance
Money
 What is the impact of (in parts of the world)
bad performance?

12.  Amazon measured the
impact of 100ms delay
 Sales dropped by 1%
 In a year that would be Typical (?) retailer
245 Million USD

13.  Instable or slow software
delays time to market
 Slow software is no longer
accepted by customers
New?

14.  Insurances like to send
paper via mail
 Not meeting deadlines can
cause
 Legal issues
Snail Mail
 Canceled contracts
 Loss of money

15. Is A Craft

16.  Calculate Execution Time
 Code x = 5ms
 Code y = 2*x = 10ms
 Know code in advance
 Waterfall approach Performance
Engineering
 Proving the performance of software
is more difficult than proving the correct function

17.  We prove functional
correctness with automated
tests
 High coverage
Look closely
 Run examples and see if they are fast

18.  Done late in project
 If done at all
How much load
breaks the system?
 No chance to fix anything

19.  Avoid human errors
 Require machine decidable
fail / pass check
 What is the measure? 42cm are fast?

20.  Functionality is independent
of the environment
 Performance characteristics
can vary
 Unusable slow
Our Environment
 Lightning fast

21.  Underpowered hardware
 Loaded with tools
and stuff
Developers
 Luckily not the production driving fast
environment

22.  More power
 But also more load
 How much faster is
production than development? Crawling Production
 Any estimation on how much better or worse the
environments are is incorrect

23.  Real performance tests
need real systems
 Test in production
 Clone production Stop playing
infrastructure

24.  Amount of data is
unpredictable
 Application usage is
unpredictable
Tweets per second
 How thought of using Twitter for build notification?

25. Dev Prod
 Test Test1  Fabian Lange
 Test Test2  Uwe Friedrichsen
 Test Test3  Mirko Novakovic
 Showing 3/3  Showing 3/6,434,867

26.  Syntethic load tests are
unrealistic
 No application has hundreds
of users doing the same
procedure again and again
Load Baselines
 Understanding real load is difficult

27.  Real usage cannot
be generated
 Real usage can be
captured & replayed
Live Systems are live
 Be careful 

28.  Continous performance tests
 Close to real setup
App Monitor
 Observe production behavior
 Fix issues fast

29.  Conflicting interests
 Development: Change
 Operations: Stability
Another Movement
 Need to work together

30. Is A Challenge

31.  Can‘t we do anything before
production?
 We want to deliver something, Let users test?
which works perfectly!

32.  Optimizations might have
no impact
 Micro-Optimizations are Missed Target
dangerous

33.  Soft Measure
 Works good for code quality
Sonar
 Are there performance best practices?

34.  Yahoo Best Practices
 Google Best Practices
 Plenty of tools
Good Waterfalls
 Work well

35.  Naive implementation looks fine
 But is not multithreaded

36.  This is threadsafe
 But slow

37.  This is correct
 Correct synchronisation is hard

38.  Check Log Level (Ugly)
 Check Log Level (Nicer)

39.  Static SimpleDateFormat is wrong
 Working with Dates
and Calendars is
very expensive!

41.  Some people misuse it as loop
 Results are unexpected behavior or slow execution

42.  Analyzes Java Bytecode
 Knows 58 Performance Bugs
 Most are rather trivial
Indeed finds bugs

43.  Detecting deadlocks
is difficult
 Many thesis's on deadlock
detection
Verifies Java
 Few code

44.  Hidden Gem
 Tries to cause Deadlocks
IBM
Support Assistant

45.  We need more and reliable
 Code Performance Metrics
 Best Practices
 Tools

46. Is A Challenging Craft

47. Q&A

48.  Art  YSlow
flickr.com/photos/37202375@N03/3490107873 developer.yahoo.com/yslow
 Magic  Pagespeed
flickr.com/photos/princes_milady/4238912548 code.google.com/speed/page-speed
 Crossroads  Java Locking
flickr.com/photos/40481200@N06/4857965280 en.wikipedia.org/wiki/Double-checked_locking
 Envelopes  PHP Ternary Operator
flickr.com/photos/creatingmotherhood/3663914542 fabien.potencier.org/article/48/the-php-ternary-
operator-fast-or-not
 Test
flickr.com/photos/cayusa/2159980025  JavaScript for .. In
stackoverflow.com/questions/500504/javascript-for-
 Scales in-with-arrays
flickr.com/photos/reinvented/309512320
 Findbugs
 Tape Measure findbugs.sourceforge.net
flickr.com/photos/hippie/2466583497
 Jlint
 World jlint.sourceforge.net
flickr.com/photos/heimdahlrecounts/4346082743
 IBM Multicore SDK
 Toys www-
flickr.com/photos/sbluerock/364123380 01.ibm.com/support/docview.wss?uid=swg21456945
 TPS
flickr.com/photos/twitteroffice/5681263084
 Bananas
flickr.com/photos/design-dog/1249337589
 Dart
flickr.com/photos/malavoda/2369876508