Programming for Performance

  • 701 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
701
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Programming for PerformanceCris HoldorphUnicon, Inc.holdorph@unicon.net
  • 2. http://www.unicon.net/
  • 3. UniconReputation basedOpen sourceHigher educationIT consulting servicesNot a product vendorTrusted partnerCustomized solutionsProject managementCommunity engagementProject and team supportOpen Source SupportActive community membersEngineering / DevelopmentDeployment / HostingCris Holdorph● holdorph@unicon.net● Twitter: @holdorph● Google Plushttp://goo.gl/BtWvU
  • 4. History LessonSummer of 1998● Unicon Offices● 6 Developers● Cisco Networking Academies Management System (CNAMS) in supportof the Cisco Networking Academy Program
  • 5. The Iron Trianglehttp://www.unicon.net/node/1350
  • 6. PerformanceMaintainabilityReusability
  • 7. PerformanceMaintainabilityReusabilitySecurity Usability
  • 8. The Iron Pentagon?PerformanceMaintainabilityReusabilitySecurity Usability
  • 9. The Iron Octagon?PerformanceMaintainabilityReusabilitySecurity UsabilityInternationalizationScalability
  • 10. http://www.flickr.com/photos/lissalou66/3473695297/
  • 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. 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."● https://github.com/jameswennmacher/AnnouncementsPortlet/commit/3af71f77ae11694233be7495238da855d6aa0753results = select * from table where items matchif results.count > 0for R in resultsdelete R from table
  • 13. O(n2) Problems● N+1 problems are pretty in comparison to N2problems● Example50 people10 items per person-----------------------------------500 querieshttp://collab.sakaiproject.org/pipermail/sakai-dev/2013-March/021736.html
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions?Uniconhttp://www.unicon.net/Cris Holdorphholdorph@unicon.net