1 / 16

Application Performance and The Trap of Object-Orientedness

Application Performance and The Trap of Object-Orientedness. Targo Tennisberg Development Manager and Self-Proclaimed Guru http://www.targotennisberg.com/tarkvara September 2008. Trap of Object-Orientedness. Tenets of OOP: abstraction, encapsulation, inheritance and polymorphism

malana
Download Presentation

Application Performance and The Trap of Object-Orientedness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ApplicationPerformance and TheTrapofObject-Orientedness Targo Tennisberg Development Manager and Self-Proclaimed Guru http://www.targotennisberg.com/tarkvara September 2008

  2. TrapofObject-Orientedness • Tenets of OOP: abstraction, encapsulation, inheritance and polymorphism • OOP is good and makes us more productive • It also reduces our level of understanding about the underlying components • Ideally, we’renotsupposedtoknowwhat’sinside a well-encapsulatedcomponent • Realityisnotquite so simple • Super easy to misuse technology • Grandmasendingyou a 500 MB video bydrag & drop • Programmersmaketheexactsamemistakes!

  3. CivilEngineeringAnalogy • If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization(Weinberg’ssecondlaw) • Everycivilengineerknowsthebasicpropertiesofthematerialsheisworkingwith • Imaginebuilding a skyscraperoutof “encapsulated” components • It’scommonforsoftwareengineersnottoknowthealgorithms and behaviorsoftheirunderlyingcomponents

  4. Example: OR Mappings • Classictask: Object-Relationalimpedancemismatch • Manydifferentframeworksbetweentheapp and DB • Mappingstendtomakethingscomplicated and imperfect. Application .Net/Java classes O-RMapper ((N)Hibernate, LINQ, ApplicationServers) SQL Database

  5. CaseStudy: SharePoint, part 1 • Special Case of an OR-Mapper • Documents, lists, web parts etc stored in a database • Thin .Net object model translates API calls to SQL • Simple APIs • New developers tend to call lots of methods • All ofthemresultin a moreorlesscomplex SQL query • Typicalsymptomsinclude: • Acceptableperformance on developer’smachine • Inactualdeploymentor stress test, operationsexhibitrandomslownessorblockages • SQL CPU/memoryoftenveryhigh • No singleobviousproblematicquery, things are sometimesfaster, sometimesslower • Usually a signofthe “EstonianCustoms” applicationmodel

  6. “Eesti Toll” applicationmodel • No centralconceptofwhatdatawerequire • Wheneveranythingisneeded, a newqueryisexecuted • Lotsof “chattiness” and extradatais sent overthewires • Samedatais sent manytimes • Deathby a thousandcuts • OK forprototypingorcertainlow risk areas, buthighlydangerousin real lifeapplications

  7. CaseStudy: SharePoint, part 2 • Reducingthe number queriesbecametheholygrail • Everyqueryexamined: dowe need it? • Combiningstrategy • DataSharingstrategy • Cachingstrategy • Thinkabouthowoftendataactuallychanges • Variousinvalidationalgorithms • Query police: specifictestsfor number ofqueries, developershadtodefendthe need forthemtoanarchitect • Result: SharepointPortal Server 2003 hadonlytwo DB queriesin order torendertheportalhomepage • Incomparison: manycustom SharePoint developmentshave 30+ queries/page • Canleadtothe “Doctor’s Office” applicationmodel

  8. “Perearst” applicationmodel • Manylittlecaches all overtheplace, just likethelinesin a doctor’soffice • Cancreatememorypressure • Significantimprovementoverthe “Eesti toll” model • Oftensufficient • Manycachescanberedundant • SQL, ADO, yourfavoriteframeworkalreadycachesomestuff

  9. CaseStudy: SharePoint, Part 3 • Cutoutasmanydatatransformations and stagesaspossible • Highlyoptimizedqueriesforcommonoperations (like list rendering) • Dataisoftendirectlytranslatedfrom SQL to HTML • Verycomplex, butefficient • Doesnotworkforcustom SharePoint development • “Hansabank” applicationmodel

  10. “Hansapank” applicationmodel • All therelevantdatacanbeprocessedinoneplace • Minimaldatatransferbetweencomponents • Downside: oftenhighlycomplex and difficulttomaintain • Useonlyperformance-criticalareas

  11. Lessonslearned • Identifywiththedata, thinkabouttheroundtrips and stagesitwillgothrough • Modelchoiceisanarchitecturaldecision • Determinewhichmodelyouwilluseearly on inthedesignphase • Verydifficulttochangeafterwards • 90% ofperformanceproblems are designedin, notcodedin • Peopleoftenthinkofperformanceassomethingthatcanbeoptimizedincodeafterthefact – itdoesn’tworkthisway • Never, everassumeyouknowanything • Profile early and often • Beafraidofthedark • Ifyoudon’tknowhow a certaincodepathworks, chances are itwillbeslow and includeunexpectedwork • Thingsgetworse on theirown • Thinkabout all aspectsofperformance • CPU, Memory, I/O, Network

  12. Lessonslearned 2 • Inspectthesource, becomeonewiththecode(LinusTorvalds) • Programmer’sbesttextbookissourcecode • Inopensource, infiniteamountsofavailablereadingmaterial • Inclosedsource, examinethebehaviorofyourbuildingblocks, see howtheybehaveindifferentconditions • Profile, profile, profile

  13. Thank You. Questions?

More Related