Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

  • Login to see the comments

  • Be the first to like this

Performance - a challenging craft

  1. 1. A Challenging Craft
  2. 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
  3. 3.  Some say: „creating software is art“ Art and software development need creativity Art
  4. 4.  Fixing performance is often considered magic Magic is something  only you understand  you do in a hard to Magic follow fashion
  5. 5.  Correctness in detail Research and verification Craft
  6. 6.  All types share  Passion  Learning  Experience Which way?
  7. 7.  Value == Money We need a business case for performance Money What is the impact of (in parts of the world) bad performance?
  8. 8.  Amazon measured the impact of 100ms delay Sales dropped by 1% In a year that would be Typical (?) retailer 245 Million USD
  9. 9.  Instable or slow software delays time to market Slow software is no longer accepted by customers New?
  10. 10.  Insurances like to send paper via mail Not meeting deadlines can cause  Legal issues Snail Mail  Canceled contracts  Loss of money
  11. 11. Is A Craft
  12. 12.  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
  13. 13.  We prove functional correctness with automated tests High coverage Look closely Run examples and see if they are fast
  14. 14.  Done late in project If done at all How much load breaks the system? No chance to fix anything
  15. 15.  Avoid human errors Require machine decidable fail / pass check What is the measure? 42cm are fast?
  16. 16.  Functionality is independent of the environment Performance characteristics can vary  Unusable slow Our Environment  Lightning fast
  17. 17.  Underpowered hardware Loaded with tools and stuff Developers Luckily not the production driving fast environment
  18. 18.  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
  19. 19.  Real performance tests need real systems Test in production Clone production Stop playing infrastructure
  20. 20.  Amount of data is unpredictable Application usage is unpredictable Tweets per second How thought of using Twitter for build notification?
  21. 21. Dev Prod Test Test1  Fabian Lange Test Test2  Uwe Friedrichsen Test Test3  Mirko Novakovic Showing 3/3  Showing 3/6,434,867
  22. 22.  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
  23. 23.  Real usage cannot be generated Real usage can be captured & replayed Live Systems are live Be careful 
  24. 24.  Continous performance tests Close to real setup App Monitor Observe production behavior Fix issues fast
  25. 25.  Conflicting interests  Development: Change  Operations: Stability Another Movement Need to work together
  26. 26. Is A Challenge
  27. 27.  Can‘t we do anything before production? We want to deliver something, Let users test? which works perfectly!
  28. 28.  Optimizations might have no impact Micro-Optimizations are Missed Target dangerous
  29. 29.  Soft Measure Works good for code quality Sonar Are there performance best practices?
  30. 30.  Yahoo Best Practices Google Best Practices Plenty of tools Good Waterfalls Work well
  31. 31.  Naive implementation looks fine But is not multithreaded
  32. 32.  This is threadsafe But slow
  33. 33.  This is correct Correct synchronisation is hard
  34. 34.  Check Log Level (Ugly) Check Log Level (Nicer)
  35. 35.  Static SimpleDateFormat is wrong Working with Dates and Calendars is very expensive!
  36. 36.  Some people misuse it as loop Results are unexpected behavior or slow execution
  37. 37.  Analyzes Java Bytecode Knows 58 Performance Bugs Most are rather trivial Indeed finds bugs
  38. 38.  Detecting deadlocks is difficult Many thesiss on deadlock detection Verifies Java Few code
  39. 39.  Hidden Gem Tries to cause Deadlocks IBM Support Assistant
  40. 40.  We need more and reliable  Code Performance Metrics  Best Practices  Tools
  41. 41. Is A Challenging Craft
  42. 42. Q&A
  43. 43.  Art  YSlow Magic  Pagespeed Crossroads  Java Locking Envelopes  PHP Ternary Operator operator-fast-or-not Test  JavaScript for .. In Scales in-with-arrays  Findbugs Tape Measure  Jlint World  IBM Multicore SDK Toys www- TPS Bananas Dart