Your SlideShare is downloading. ×
Performance  - a challenging craft
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Performance - a challenging craft


Published on

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

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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