"Performanceproblemer er som et isbjerg, meget af det er skjult og vil først blive opdaget, når det er for sent."
"Performanceproblemer dukker ikke op i udvikling, heller ikke i unit test. De dukker op i produktion."
"Ofte er det arkitekturproblemer som dukker op i produktion - det er ikke nemt at fixe!"
"Performancetest bliver udført sent eller aldrig."
Da Alois Reitbauer kommer med sine udsagn, bliver der nikket stiltiende og gryntet anerkendende blandt de 40-50 tilhørere til hans foredrag "Building for Performance and Scalability", der finder sted på udvikler-konferencen QCon.
Efter Alois Reitbauers præsentation har Computerworld talt med ham samt Michael Nygard, forfatter til nyklassikeren "Release IT", om, hvordan man udvikler systemer, der ikke mister pusten, så snart man rykker fra udviklingsmiljøet over test-miljøet og ind i den virkelige verden; produktionsmiljøet.
Alois Reitbauer er teknologistrategiker fra Dynatrace, der leverer konsulentydelser og værktøjer til performancemålinger og -forbedringer til store kunder i blandt andet den finansielle sektor.
Med over 10 års erfaring som udvikler og arkitekt indenfor .Net- og J2EE-verdenen kender Alois Reitbauer til udviklernes ømme punkter og dårligdomme.
Problemløsning i et fjendtligt miljø
Der er stort fokus på de funktioner som et nyt system skal understøtte, men mindre fokus på non-funktionelle krav som performance.
Den kan man jo altid forbedre på et senere tidspunkt, er desværre en udbredt holdning i branchen.
Men det er en forkert indstilling, som giver problemer, mener Alois Reitbauer, der jævnligt kommer ud til kunder, når behovet for forbedringer ikke længere er noget kunderne kan skubbe foran sig. Forbedringerne skal implementeres her og nu, fordi lange svartider er ved at kvæle virksomhedens konkurrenceevne.
Systemerne, der ofte betegnes som forretningskritiske, har forvandlet sig til forretningstruende systemer.
"Vi kommer som regel ind, når problemerne er opstået, men så lytter kunderne også til os, siger Alois Reitbauer.
Det betyder, at problemerne skal identificeres i produktionsmiljøet, hvilket Alois Reitbauer betegner som et "fjendtligt" miljø.
"Har du prøvet at have 5-6 mennesker stående bag dig, mens du forsøger at identificere en fejl eller en performanceflaskehals i et produktionsmiljø, så ved du, hvad jeg taler om," siger Alois Reitbauer.
Målinger på softwarelag
Dynatraces værktøj kan måle på de forskellige softwarelag i de ofte heterogene systemer, der kører på tværs af forskellige platforme.
Her identificeres metodekald eller servlets, der bruger mange ressourcer eller tager lang tid at eksekvere, kode, der foretager mange gentagende SQL-kald eller SQL-kald som tager lang tid, tråde og locks der giver synkroniseringsproblemer, komponenter med umådeholdent mange remote calls, services der overfører umådeholdent store mængder data, services der tager for lang tid at udføre, kode med memoryleaks og en række andre elementer, der indikerer flaskehalsproblemer.
Forebyggelse i udvikling fremfor helbredelse i produktion
Alois Reitbauer argumenterer for, at mange af den slags situationer kan undgås, hvis udviklerne tænker mere i performance management-baner ved udviklingen af systemer.
"50 procent af performance problemer kan findes i udviklingsfasen, men desværre ignorerer virksomheder dem så lang tid de kan," vurderer Alois Reitbauer.
Tænk på dit system ud fra kø-teori
Han understreger, at det ikke er et spørgsmål om at foretage præmatur optimering.
"Det handler ikke om at jagte millisekunder, men om at sikre en grundlæggende sund performance," siger Alois Reitbauer.
Ved at tænke på sit system i en kø-teoretisk optik, kan udviklerne forudse, hvor der kan opstå flaskehalse og arbejde på at undgå at de udfolder sig til forretnings
"Der er nogle fysiske begrænsende faktorer som CPU, memory, IO, netværk og adgang til delte ressourcer," siger Alois Reitbauer.
Alois Reitbauer anbefaler også at kigge efter performance-anti-patterns i systemarkitekturen. Anti-patterns er arkitekturelementer som man af erfaring ved giver problemer.
Det kan eksempelvis være komplekse afhængigheder mellem frameworks, og forkert opfattelse af et frameworks anvendelse af caching.
Lær dine frameworks at kende
Netop frameworks som Spring, Groovy, Grails, Hibernate og andre vinder i stigende grad indpas i virksomhedernes software-arkitekturer.
Det er en stor hjælp og kan være med til at speede udviklingshastigheden op, men Alois Reitbauer advarer imod, at anvende diverse frameworks som en black-box. Det er nødvendigt at forstå, hvordan frameworks fungerer indeni for at undgå performanceoverraskelser.
"Det er godt at bruge lidt tid på at sætte sig ind i frameworket. Jeg siger ikke, at man skal lære koden bag frameworket udenad, men en runtime analyse kan give et godt indblik i, hvad der foregår.
Hvis jeg eksempel har en antagelse om, at hvis jeg koder noget på en bestemt måde, så vil det tilgå cachen og ikke gå direkte til databasen, så er det vigtigt, at jeg undersøger om den antagelse passer," påpeger Alois Reitbauer.
Derfor opfordrer Alois Reitbauer udviklere til at bruge lidt tid på at forstå hvordan de forskellige frameworks fungerer.
"Det er ligesom agil udvikling, hvor man lægger vægt på par-programmering for at man lærer koden at kende,. Vi siger det samme om frameworks; de skal forstås," anbefaler Alois Reitbauer.
Udviklerens pligt at forstå tredjepartskode
Men ryger ideen så ikke med at frameworks sparer tid, hvis man skal bruge tid på at sætte sig ind i deres opbygning?
"Folk bruger frameworks, blandt andet fordi det sparer tid i udviklingen. Men man skal stadig forstå, hvordan softwaren virker, ellers er der risiko for at man bruger det forkert. Udviklernes tid bruges ikke til bygning af frameworket, men til at forstå frameworket. Der er forskel på at forstå koden fremfor at kode den selv. Der er mandeår til forskel på at kode Hibernate og til at forstå den," uddyber Alois Reitbauer, der på sin blog blandt andet giver et indblik i hvordan Hibernate anvender caching.
Alois Reitbauer mener, det er en udviklers pligt at tredjepartskode som frameworks anvendes på en optimal måde.
"Det er dit job og dit ansvar at trejdepartskode anvendes korrekt. Management kan ignorere det i en tid, men det vil ramme dem på et tidspunkt og så vil det koste væsentligt mere tid at gøre tingene rigtigt," siger Alois Reitbauer.
Det er en vurdering som deles af Mr. Troubleshooter, Michael Nygard, forfatter til it-nyklassikeren "Release IT".
Han opfordrer til, at udviklere anvender open source frameworks, da det giver god mulighed for at forstå frameworkets opbygning. Samtidigt er det uvurderligt at have adgang til kildekoden, når performance pludselig forringes eller systemet står helt af.
Noget som kan være forårsaget af et frameworks indre opbygning.
Mr. Troubleshooter: Anvend open source
Michael Nygard erklærer sig enig i, at udviklere bør vide, hvordan frameworks fungerer internt.
"Der er mange fordele ved abstraktioner som frameworks. Spring, Hibernate og Grails er gode frameworks. Det bedste er, at det forhindrer folk i at skrive deres eget. Det er store offentligt tilgængelige frameworks som anvendes i en mængde forskellige situationer, så der er gode chancer for at andre vil ramme en bug, før du gør," siger Michael Nygard.
Men hvis man bliver ramt af en bug, er det vitalt at have adgang til kildekoden.
"Abstraktioner har en tendens til at lække. Ofte opstår problemerne på et lavere abstraktionsniveau end der hvor du befinder dig. Der kan være fejl i javasocket eller i httpurlconnection objekt. Så skal man ned og se på pakker i netværket og lignende.
Det er bedre at anvende open source framework, da det giver dig mulighed for at forstå hvad der foregår, når abstraktionen lækker. Er det proprietær kode, har du kun en binary, hvilket gør det svært at gennemskue. I den situation skal man råbe leverandøren op, hvilket kan tage tid," siger Michael Nygard.
"Jeg er selv en tinker. Jeg åbner ethvert framework for at få en ide om, hvordan det virker; hvordan sql-sætningerne genereres og den slags. Du kan ikke forstå det on the fly, når problemerne opstår," lyder det fra Michael Nygard, der giver følgende anbefaling til udviklere:
"Kend landemærkerne i dine frameworks. Det gør det nemmere at finde ud af årsagerne til fejlene, når de opstår."
Flere udfordringer nu
Ifølge Alois Reitbauer bliver opgaven med at sikre ordentlig performance ikke mindre for tiden.
"Der er flere udfordringer nu. De fysiske love ændrer sig ikke. CPU, IO og andre ressourcer er stadig fysiske begrænsninger. Samtidig bliver systemerne mere komplicerede og vanskeligere at håndtere," siger Alois Reitbauer, der blandt peger på den serviceorienterede arkitektur, der er med til at gøre performance-udfordringen større.
"Der er hele SOA-trenden med forbundne services. Systemerne bliver større og du har mindre kontrol over koden, da nogle services udvikles af andre," siger Alois Reitbauer, der ser virksomheder med flere hundrede services i infrastrukturen.
Etabler benchmarks og mål
"Du ved ikke hvad der foregår uden indsigt ved hjælp af målinger," siger Alois Reitbauer, der anbefaler at udviklere selv opstiller non-funktionelle krav, hvis ikke de specificeres af forretningen.
"Det er et generelt problem ved performance management, at der ofte ikke er nogle målemærker at holde svartider op imod. Hvis man ikke har nogle non-funktionelle krav, så opstil selv nogen. Skriv testcases og se hvordan det føles og få så feedback fra kunden," anbefaler Alois Reitbauer.
Når systemet først er i produktion vil der nemlig uundgåeligt komme fokus på den slags, så det er bedre at tage det tidligt i forløbet.
Samtidig sikrer benchmarks og målinger, at man ikke begynder at foretage præmatur optimering.
Fokuser på det rigtige
"Der er risiko for, at man optimerer på det forkerte, hvis man ikke måler," siger Alois Reitbauer og nævner et eksempel.
"Der var et projekt, hvor XML-processering blev anset for at være et potentielt performance problem. Alle ved jo, at XML-processering tager tid. Derfor var projektet klar til at afsætte ressourcer til at optimere XML-processeringen. Men da vi målte hele transaktionen som XML-processeringen var en del af, tog det faktisk kun fem procent af hele transaktionstiden af behandle XML-data," fortæller Alois Reitbauer.
Alois Retbauer understreger, at performance management i udviklingsfasen ikke erstatter andre performance management-aktvitieter som load test, performance test og deployment test.
"Du kan ikke gøre det hele i udvikling," siger Alois Reitbauer, men de fleste kan gøre meget mere, end de gør i dag.
