Programming for Performance


Published on

Programming for Performance, a conference presentation presented at the Apereo 2013 conference on June 5, 2013.

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

No notes for slide

Programming for Performance

  1. 1. Programming for PerformanceCris HoldorphUnicon,
  2. 2.
  3. 3. UniconReputation basedOpen sourceHigher educationIT consulting servicesNot a product vendorTrusted partnerCustomized solutionsProject managementCommunity engagementProject and team supportOpen Source SupportActive community membersEngineering / DevelopmentDeployment / HostingCris Holdorph●● Twitter: @holdorph● Google Plus
  4. 4. History LessonSummer of 1998● Unicon Offices● 6 Developers● Cisco Networking Academies Management System (CNAMS) in supportof the Cisco Networking Academy Program
  5. 5. The Iron Triangle
  6. 6. PerformanceMaintainabilityReusability
  7. 7. PerformanceMaintainabilityReusabilitySecurity Usability
  8. 8. The Iron Pentagon?PerformanceMaintainabilityReusabilitySecurity Usability
  9. 9. The Iron Octagon?PerformanceMaintainabilityReusabilitySecurity UsabilityInternationalizationScalability
  10. 10.
  11. 11. Finally!● Finalizers prevent objects from being garbage collected until the finalizermethod is run● There is no requirement of the JVM to run a finalizer method, just to notcollect the object until it does● Long Garbage Collections and eventually Out of Memory exceptions
  12. 12. N + 1 Problems● "At my current client, after a couple of weeks of fixing N+1 problems,development managed to reduce the database load from 22K TPS to 8KTPS, a rather large decrease. It was clear that their attitude indeveloping the original code was that data access is free."● = select * from table where items matchif results.count > 0for R in resultsdelete R from table
  13. 13. O(n2) Problems● N+1 problems are pretty in comparison to N2problems● Example50 people10 items per person-----------------------------------500 queries
  14. 14. Cache Everything (NOT)● Caching can fix many problems● Caching can hide many problems that need to be found● Ehcache○ Multi-node distributed cache○ Cache to disk● Caching data that is quicker to recreate (memory is not free)● Example 1: Caching XML trees created from a normalized database● Example 2: Calling web services to an external system● Example 3: When 4 is better than 16
  15. 15. TransactionMismanagement● Example○ Regrade all assessments○ Do all of the regrades in one transaction○ All changed data has to be stored in a temporary location○ That location ran out of space, site crashed● Example○ Many uses of database connections in Sakai○ Obtain connection, read or write some data, release connection○ New user login can take over 100 calls to the database (and thatsonly the ones that use Sakais SqlService facility)
  16. 16. Concurrency Issues● Dirty Data● Deadlocks● Example:○ System would gradually become unresponsive○ StackTraces indicated threads blocking on ehcache○ Cache where multiple callers would block on a cache miss for keyXYZ until key XYZ could be populated○ The blocking ehcache was hidden and not documented● Example:○ Instance variables in a multi-threaded web application
  17. 17. Bad Algorithms● Example○ Fantasy Football draft○ Worked fine for 100 teams in testing○ Failed at scale with 80,000 teams○ N2problem pulling, processing, then deleting a row from a databasetemporary table○ Database Temporary tables have no indexes○ Result was a full table scan for each SELECT and DELETE● Example○ Sakai rename item in resources○ Copy item, then Delete item○ Item might be a 500 meg video
  18. 18. Calls to ExternalSystems● Writing a component / service that hides the details of an externalsystem and looks very Service-Oriented to the caller● Set of services does not match what was needed exactly● Call a service to get an item, which behind the scenes calls an externalsystem● Call a service to get a list of items● Service doesnt exist, so create a new interface that returns a list● New method makes a call for each item to the original service● Eventually you have N calls to the external system● SOAP Web Service calls are extremely expensive
  19. 19. Database Tips● For Basic Web Applications the ideal pattern would be1. Load Data2. Business Logic and Data Update3. Render View● Open Session in View filter/pattern does not follow this pattern● Close Transactions and release database sessions/connections to avoidlocks● Avoid LIKE queries unless you have a full text index on the column (thedefault index is B-Tree which does not help with LIKE queries)
  20. 20. Hibernate Tips● Use HQL and fetch joins to minimize round trips to the database● Stored Procedures can work but are not portable● When encountering a LazyInitializationException try to query the data tobegin with instead of resorting to Open Session in View● If possible use Optimistic Locking and deal with the Exception● Otherwise use Pessimistic Locking and SELECT FOR UPDATE
  21. 21. Batch Processing● Similar to Caching Batch Processing can be good or bad depending onthe circumstances● Batch Processing may save several round trips to an external system● Batch Processing may cause you to run out of memory by reading in toomany entities at once● Batch Processing can cause an entire batch to fail if only one recordfails
  22. 22. Loop Unrolling● N+1 Problems are extremely common● You can not eliminate all loops● Some data does not need to be obtained each iteration of a loopfor X in listvalue = get VALUE from external systemset value on Xval = get VAL from external systemfor X in listset val on X
  23. 23. Strings● String is an Immutable class in Java, manipulation of the String classresults in Object creation● StringBuffer is a mutable string that can be changed without new objectcreation● StringBuffer is a thread safe class● StringBuilder is a non-thread safe version of StringBuffer
  24. 24. Stringsfor (int i=0; i < source.length; i++) {doSomething(i + ":" + source[i]);}StringBuffer temp = new StringBuffer();for (int i=0; i < source.length; i++) {temp.setLength(0);temp.append(i).append(:).append(source[i]);doSomething(temp);}
  25. 25. Classes, Methods,Variables● Local variables are often (always?) faster than member variables● Primitive types are faster than the Wrapper types○ Be careful of autoboxing● Final methods can be handled quicker by the JVM● Deep class inheritance hierarchy can lead to slower performance
  26. 26. Balancing the Plates● Logging is not free● Optimizing for performance? Eliminate logging● Want to EVER debug your application? Make sure you do logging● CODE DUPLICATION might result in higher performance.... Is it worthit?
  27. 27. Various Comments● Performance is dependent on data as well as code. Different data canmake identical code perform very differently.● Always start tuning with a baseline measurement● Creating an Exception is a costly operation because of filling in thestacktrace● There is no best algorithm or best data structure, only best fit for aspecific context
  28. 28. Questions?Unicon