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 simpleSuper easy to misuse technology

Grandma sending you a 500 MB video by drag & dropProgrammers make the exact same mistakes!

Civil Engineering AnalogyIf 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 pressureSignificant improvement over the “Eesti toll” model

Often sufficientMany 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 ownThink about all aspects of performance

CPU, 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?