Upload
raymond-elliott
View
221
Download
1
Tags:
Embed Size (px)
Citation preview
Application Performance and
The Trap of Object-Orientedness
Targo TennisbergDevelopment Manager and Self-Proclaimed Guru
http://www.targotennisberg.com/tarkvara
September 2008
Trap of Object-Orientedness
Tenets of OOP: abstraction, encapsulation, inheritance and polymorphismOOP is good and makes us more productiveIt also reduces our level of understanding about the underlying componentsIdeally, we’re not supposed to know what’s inside a well-encapsulated component
Reality is not quite so simple
Super easy to misuse technologyGrandma sending you a 500 MB video by drag & dropProgrammers make the exact same mistakes!
Civil Engineering Analogy
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization (Weinberg’s second law)Every civil engineer knows the basic properties of the materials he is working withImagine building a skyscraper out of “encapsulated” componentsIt’s common for software engineers not to know the algorithms and behaviors of their underlying components
Example: OR Mappings
Classic task: Object-Relational impedance mismatchMany different frameworks between the app and DBMappings tend to make things complicated and imperfect. Database
O-R Mapper ((N)Hibernate, LINQ, Application Servers)
Application
.Net/Java classes
SQL
Case Study: SharePoint, part 1
Special Case of an OR-MapperDocuments, lists, web parts etc stored in a databaseThin .Net object model translates API calls to SQLSimple APIs
New developers tend to call lots of methodsAll of them result in a more or less complex SQL query
Typical symptoms include:Acceptable performance on developer’s machineIn actual deployment or stress test, operations exhibit random slowness or blockagesSQL CPU/memory often very highNo single obvious problematic query, things are sometimes faster, sometimes slower
Usually a sign of the “Estonian Customs” application model
“Eesti Toll” application model
No central concept of what data we requireWhenever anything is needed, a new query is executedLots of “chattiness” and extra data is sent over the wiresSame data is sent many timesDeath by a thousand cutsOK for prototyping or certain low risk areas, but highly dangerous in real life applications
Case Study: SharePoint, part 2
Reducing the number queries became the holy grailEvery query examined: do we need it?
Combining strategyData Sharing strategyCaching strategy
Think about how often data actually changesVarious invalidation algorithms
Query police: specific tests for number of queries, developers had to defend the need for them to an architectResult: Sharepoint Portal Server 2003 had only two DB queries in order to render the portal homepage
In comparison: many custom SharePoint developments have 30+ queries/page
Can lead to the “Doctor’s Office” application model
“Perearst” application model
Many little caches all over the place, just like the lines in a doctor’s office
Can create memory pressure
Significant improvement over the “Eesti toll” model
Often sufficient
Many caches can be redundant
SQL, ADO, your favorite framework already cache some stuff
Case Study: SharePoint, Part 3
Cut out as many data transformations and stages as possibleHighly optimized queries for common operations (like list rendering)Data is often directly translated from SQL to HTMLVery complex, but efficientDoes not work for custom SharePoint development “Hansabank” application model
“Hansapank” application model
All the relevant data can be processed in one placeMinimal data transfer between componentsDownside: often highly complex and difficult to maintain
Use only performance-critical areas
Lessons learned
Identify with the data, think about the roundtrips and stages it will go throughModel choice is an architectural decision
Determine which model you will use early on in the design phaseVery difficult to change afterwards90% of performance problems are designed in, not coded in
People often think of performance as something that can be optimized in code after the fact – it doesn’t work this way
Never, ever assume you know anythingProfile early and oftenBe afraid of the dark
If you don’t know how a certain code path works, chances are it will be slow and include unexpected work
Things get worse on their own
Think about all aspects of performanceCPU, Memory, I/O, Network
Inspect the source, become one with the code(Linus Torvalds)Programmer’s best textbook is source codeIn open source, infinite amounts of available reading material In closed source, examine the behavior of your building blocks, see how they behave in different conditions
Profile, profile, profile
Lessons learned 2
Thank You. Questions?