Find et memory leak

Hvis man har en stor web-applikation og en masse brugere, kan man tit løbe ind i problemer med serverens hukommelse. Jeg havde heldigvis sat alarmsystemer op til at gøre mig opmærksom på, hvis det var ved at være galt fat.

Alarmen kom - men baseret på antallet af brugere 'burde' den ikke være kommet (endnu). Jeg kunne derfor hurtigt konkludere at der var et memory leak af en art.

Jeg fik et tip om at bruge ANTS Profiler fra Red-Gate - og det skulle vise sig at være et godt tip.

Sådan brugte jeg det:

1. Jeg startede ANTS Profiler og blev spurgt om jeg ville undersøge performance eller memory.

2. Jeg valgte den ASP.NET-applikation som jeg havde mistænkt for at være synderen.

3. Så kørte profileren. Jeg afprøvede så nogle af de mistænkte scenarier i applikationen og tog et Snapshot af hukommelsesforbruget hver gang, for at kunne sammenligne med tidligere Snapshots og identificere om der var unødigt ekstra-forbrug.

Det viste sig at den ASP.NET-applikation var helt fin, men da jeg gentog øvelsen med en anden applikation var der bid. Hukommelsesforbruget steg for hver gang jeg viste en brugergrænseflade.

I ANTS Profiler skiftede jeg faneblad til "All objects" og sorterede på størrelse. Jeg kunne se de største objekter var nogle streng-objekter og dem blev der bare flere og flere af. Ved et klik på objektet kunne jeg se hvorfra det var blevet skabt og hvor det var placeret. Det viste sig at være en streng som skulle bruges i et sekund, men blev lagt i cachen i 23 timer.

Problem løst!

Test af software

I titlen på det første indlæg på DotNyt, indgår ordet "Test". Alt skal testes! Her kommer det helt naturligt. Jeg vil ikke gå i gang med at skrive en masse eftertænksomme ting, f.eks. om testprocedurer, før jeg ved om bloggen virker.

Det gør den! Jeg har lige afprøvet den og jeg kan sørme se det virker.

Det er tankevækkende at jeg er mere motiveret til at teste en blog, end jeg er til at teste de web-applikationer jeg lever af at udvikle. Jeg er ikke i tvivl om, at det er fordi det rammer mig direkte hvis jeg spilder tid på at opsætte en blog som ikke virker.

Nøgleordet er direkte. Når en kunde bestiller en vigtig opgave hos en udviklingsvirksomhed, bliver udvikleren selv kun ramt indirekte hvis der er fejl i løsningen. Kunden bliver ramt direkte, for det er kunden som skal bruge systemet og som muligvis mister penge for hvert sekund der går med fejl i systemet.

Systemudvikleren bliver ramt indirekte. Kunden er ikke tilfreds, bestiller ikke opgaver i den virksomhed længere og systemudvikleren mister sit job. Skulle den alvorlige konsekvens ikke motivere systemudvikleren til at teste? Nej, for det er en indirekte konsekvens.

Derfor skal testproceduren foregå på en måde som kan mærkes direkte på systemudvikleren. Der skal være belønninger for at udarbejde en fejlfri løsning - og omvendt skal der være straf for at lave fejl. Det kunne handle om penge, men det er der visse problemer ved. Systemudvikleren får i forvejen penge for at komme på arbejde - hvorfor skal vedkommende belønnes yderligere for rent faktisk at udføre sit job?

Løsningen er at lade en anden person end systemudvikleren teste løsningen. Systemudvikleren føler en straf når der bliver fundet fejl af en anden person og systemudvikleren derefter skal rette fejlen. Det er irriterende at få påpeget sine egne fejl og det er kedeligt at rette fejl. Også derfor skal en systemudvikler altid rette sine egne fejl. Systemudvikleren undgår dette hvis løsningen er fejlfri til at starte med og det er motiverende!