Application Performance and the Trap of Object ... - Targo Tennisberg

streakconvertingSoftware and s/w Development

Dec 13, 2013 (3 years and 6 months ago)

97 views

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

OOP is good and makes us more productive

It also reduces our level of understanding about the
underlying components

Ideally
,
we’re

not

supposed

to

know

what’s

inside

a
well
-
encapsulated

component

Reality

is

not

quite

so
simple

Super easy to misuse technology

Grandma

sending

you

a 500 MB video
by


drag

&
drop

Programmers

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

with

Imagine

building

a
skyscraper

out

of


encapsulated

components

It’s

common

for

software

engineers

not

to

know

the

algorithms

and
behaviors

of

their

underlying

components

Example
: OR
Mappings

Classic

task
:
Object
-
Relational

impedance

mismatch

Many

different

frameworks

between

the

app

and DB

Mappings

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
-
Mapper

Documents, lists, web parts etc stored in a database

Thin
.Net

object model translates API calls to SQL

Simple APIs

N
ew

developers tend to call lots of
metho
ds

All
of

them

result

in

a
more

or

less

complex

SQL
query

Typical

symptoms

include
:

Acceptable

performance

on
developer’s

machine

In

actual

deployment

or

stress test,
operations

exhibit

random

slowness

or

blockages

SQL
CPU/memory

often

very

high

No
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

require

Whenever

anything

is

needed
, a
new

query

is

executed

Lots

of


chattiness
” and
extra

data

is

sent
over

the

wires

Same

data

is

sent
many

times

Death

by

a
thousand

cuts

OK
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

grail

Every

query

examined
:
do

we

need
it
?

Combining

strategy

Data

Sharing

strategy

Caching

strategy

Think

about

how

often

data

actually

changes

Various

invalidation

algorithms

Query
police
:
specific

tests

for

number
of

queries
,
developers

had

to

defend

the

need
for

them

to

an

architect

Result
:
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

possible

Highly

optimized

queries

for

common

operations

(
like

list
rendering
)

Data

is

often

directly

translated

from

SQL
to

HTML

Very

complex
,
but

efficient

Does

not

work

for

custom

SharePoint
development




Hansabank

application

model

“Hansapank”
application

model

All
the

relevant

data

can

be

processed

in

one

place

Minimal

data

transfer

between

components

Downside
:
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

through

Model

choice

is

an

architectural

decision

Determine

which

model

you

will

use

early

on
in

the

design

phase

Very

difficult

to

change

afterwards

90%
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

anything

Profile
early

and
often

Be

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

performance

CPU,
Memory
, I/O, Network


Inspect

the

source
,
become

one

with

the

code

(
Linus

Torvalds
)

Programmer’s

best

textbook

is

source

code

In

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?