Performance - a challenging craft

In my talk at socrates 2011, I descrived why performance is a craft and what to do to ensure great performance. I concluded with a few best practies and wonder if there are more

Transcript

1. A Challenging Craft
2. Customer Fabian  My day to day job is to help customers fixing software performance  People really struggle with performance  But most of them struggle with coding as well That‘s me  If creating good software is a craft, performance should be one as well
4. Art  Some say: „creating software is art“  Art and software development need creativity
5. Magic  Fixing performance is often considered magic  Magic is something  only you understand  you do in a hard to follow fashion
6. Craft  Correctness in detail  Research and verification
7. Which way?  All types share  Passion  Learning  Experience
11. Money (in parts of the world)  Value == Money  We need a business case for performance  What is the impact of bad performance?
12. Typical (?) retailer  Amazon measured the impact of 100ms delay  Sales dropped by 1%  In a year that would be 245 Million USD
13. New?  Instable or slow software delays time to market  Slow software is no longer accepted by customers
14. Snail Mail  Insurances like to send paper via mail  Not meeting deadlines can cause  Legal issues  Canceled contracts  Loss of money
15. Is A Craft
16. Performance Engineering  Calculate Execution Time  Code x = 5ms  Code y = 2*x = 10ms  Know code in advance  Waterfall approach  Proving the performance of software is more difficult than proving the correct function
17. Look closely  We prove functional correctness with automated tests  High coverage  Run examples and see if they are fast
18. How much load breaks the system?  Done late in project  If done at all  No chance to fix anything
19. 42cm are fast?  Avoid human errors  Require machine decidable fail / pass check  What is the measure?
20. Our Environment  Functionality is independent of the environment  Performance characteristics can vary  Unusable slow  Lightning fast
21. Developers driving fast  Underpowered hardware  Loaded with tools and stuff  Luckily not the production environment
22. Crawling Production  More power  But also more load  How much faster is production than development?  Any estimation on how much better or worse the environments are is incorrect
23. Stop playing  Real performance tests need real systems  Test in production  Clone production infrastructure
24. Tweets per second  Amount of data is unpredictable  Application usage is unpredictable  How thought of using Twitter for build notification?
25. Dev  Test Test1  Test Test2  Test Test3  Showing 3/3  Fabian Lange  Uwe Friedrichsen  Mirko Novakovic  Showing 3/6,434,867 Prod
26. Load Baselines  Syntethic load tests are unrealistic  No application has hundreds of users doing the same procedure again and again  Understanding real load is difficult
27. Live Systems are live  Real usage cannot be generated  Real usage can be captured & replayed  Be careful 
28. App Monitor  Continous performance tests  Close to real setup  Observe production behavior  Fix issues fast
29. Another Movement  Conflicting interests  Development: Change  Operations: Stability  Need to work together
30. Is A Challenge
31. Let users test?  Can‘t we do anything before production?  We want to deliver something, which works perfectly!
32. Missed Target  Optimizations might have no impact  Micro-Optimizations are dangerous
33. Sonar  Soft Measure  Works good for code quality  Are there performance best practices?
34. Good Waterfalls  Yahoo Best Practices  Google Best Practices  Plenty of tools  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. Indeed finds bugs  Analyzes Java Bytecode  Knows 58 Performance Bugs  Most are rather trivial
43. Verifies Java  Detecting deadlocks is difficult  Many thesis's on deadlock detection  Few code
44. IBM Support Assistant  Hidden Gem  Tries to cause Deadlocks
45.  We need more and reliable  Code Performance Metrics  Best Practices  Tools
46. Is A Challenging Craft
47. Q & A
48.  Art flickr.com/photos/37202375@N03/3490107873  Magic flickr.com/photos/princes_milady/4238912548  Crossroads flickr.com/photos/40481200@N06/4857965280  Envelopes flickr.com/photos/creatingmotherhood/3663914542  Test flickr.com/photos/cayusa/2159980025  Scales flickr.com/photos/reinvented/309512320  Tape Measure flickr.com/photos/hippie/2466583497  World flickr.com/photos/heimdahlrecounts/4346082743  Toys flickr.com/photos/sbluerock/364123380  TPS flickr.com/photos/twitteroffice/5681263084  Bananas flickr.com/photos/design-dog/1249337589  Dart flickr.com/photos/malavoda/2369876508  YSlow developer.yahoo.com/yslow  Pagespeed code.google.com/speed/page-speed  Java Locking en.wikipedia.org/wiki/Double-checked_locking  PHP Ternary Operator fabien.potencier.org/article/48/the-php-ternary- operator-fast-or-not  JavaScript for .. In stackoverflow.com/questions/500504/javascript-for- in-with-arrays  Findbugs findbugs.sourceforge.net  Jlint jlint.sourceforge.net  IBM Multicore SDK www- 01.ibm.com/support/docview.wss?uid=swg21456945