Kunderne klager over, at produktet er tungt, og det første forslag er ofte at købe større servere. Det virker af og til i en uge eller to, og så er klagerne tilbage, og regningen er højere. Langsomhed har næsten altid en bestemt årsag, som kan findes med målinger. I de fleste SaaS-produkter ligger den i database og forespørgsler, og mere serverkraft skjuler den kun for en tid. Denne artikel giver en rækkefølge, en ledelse kan følge med i: Få præciseret klagen, mål, hvor tiden går, og tag de hyppigste årsager først. Den tager også situationen, hvor én kunde gør produktet langsomt for alle.
Gør klagen konkret
“Det er langsomt” dækker over mange forskellige problemer. Stil supporten og kunderne de samme spørgsmål hver gang:
- Hvilken handling er langsom? Hele produktet eller én skærm?
- Hvornår? Hele dagen, på bestemte tidspunkter eller efter en bestemt release?
- Hvem? Alle kunder, store kunder eller en enkelt?
- Siden hvornår? Pludseligt eller gradvist?
Svarene peger i vidt forskellige retninger. Pludselig langsomhed efter en release peger på den ændring. Gradvis langsomhed peger på vækst i data. Langsomhed klokken ni peger på kapacitet eller et job, der kører samtidig med brugerne. Én kunde peger på kundens datamængde.
Mål, før I ændrer noget
Uden målinger bliver det gætteri, og udviklerne ender med at optimere det, de har lyst til. Det rette værktøj hedder APM (application performance monitoring), og det viser, hvor tiden går i en forespørgsel: i koden, i databasen eller i kald til eksterne tjenester. Mange teams har det allerede, uden at nogen kigger.
Tre tal er nyttige for ledelsen:
- Svartid på de vigtigste handlinger, set over tid.
- Svartiden for de langsomste forespørgsler. Gennemsnit skjuler dem, der rammer de mest aktive kunder.
- Hvor stor en del af svartiden der går i databasen.
Mål også hele vejen til brugeren. En side kan blive sendt hurtigt fra serveren og stadig føles langsom, fordi browseren skal hente en stor mængde kode. Det er en anden type problem og løses et andet sted.
De hyppigste årsager i databasen
Når I har målt, plejer de samme fund at dukke op. Få dem forklaret af jeres udviklere i det her sprog.
Manglende indeks. Et indeks er en opslagsstruktur, som gør, at databasen hurtigt kan finde rækker. Uden det læser den hele tabellen. Med lidt data mærker ingen noget. Med meget data bliver det en af de største årsager til langsomhed, og det er ofte en billig rettelse.
Mange små opslag. Koden henter en liste og laver derefter et ekstra opslag for hver række. Fagfolk kalder det N+1-problemet. Det ses sjældent i test med få rækker og kan være ødelæggende i drift. Det opstår ofte ubemærket, når koden bruger et bibliotek, der skjuler databasekaldene.
Tunge rapporter i driften. En rapport over flere år kører oven på samme database, som brugerne arbejder i. Løsningen er at flytte rapporter til en læsekopi eller køre dem om natten.
Låsninger. Et langt job holder fast i data, andre venter på. Det viser sig som tilfældig langsomhed, der kommer og går.
Forældede statistikker og opsætning. Databasen skal jævnligt vedligeholdes. Uden en ejer kører den på standardindstillinger.
Uden for databasen
Hvis databasen er i orden, så se på resten:
- Eksterne kald. Et kald til en betalingstjeneste eller en sprogmodel midt i en forespørgsel gør jer afhængige af deres svartid. Læg den slags i baggrunden, hvor det kan lade sig gøre.
- Baggrundsjob. Import og eksport bruger ressourcer, der mangler i brugerfladen.
- Mellemlager (cache). Mangler det, gentages dyrt arbejde. Er det for aggressivt, ser brugerne gamle data.
- Filer og billeder. Store filer sendt direkte fra serveren frem for via en tjeneste, der er bygget til det.
Når én kunde gør produktet langsomt for alle
Fagudtrykket er “noisy neighbor”, den larmende nabo. Kunderne deler platform, og én stor kunde bruger så meget, at andre mærker det. Et tænkt eksempel: En kunde importerer sin historik midt på dagen, og alle andre oplever, at produktet går i stå.
Find ud af, hvem det er, ved at se på forbrug pr. kunde. Der er så fire veje, ofte i kombination:
- Grænser. Begræns, hvor mange kald eller job en kunde må køre ad gangen.
- Køer. Lad tunge job vente på deres tur og køre med lavere prioritet.
- Tidspunkt. Flyt import og eksport væk fra arbejdstiden, og tal med kunden om det.
- Adskillelse. Giv de største kunder egne ressourcer. Det er den dyreste løsning i drift og et arkitekturvalg, se en installation til hver kunde.
Læg desuden kundetypen ind i aftalen, så store kunder ved, hvad produktet er bygget til. Står den store kunde først i køen, så læs svaret på spørgsmålet om ti gange så meget.
Hvornår større servere er rigtigt
Større maskiner er et fint værktøj, når målingerne viser, at de faktisk er ved at løbe tør, og som en midlertidig hjælp, mens I retter årsagen. Skriv ned, hvad I udskyder, så den midlertidige løsning ikke bliver permanent. Kig også på regningen, for den slags beslutninger bliver hurtigt usynlige, se cloudregningen vokser.
Hold det nede
Langsomhed kommer igen, hvis ingen holder øje. Tilføj en fast måling af de vigtigste handlinger i overvågningen, en grænse for hvor langsomme de må blive, og en test med realistisk datamængde før større releases. Gæld i databasen er ofte en del af den tekniske gæld, I allerede har. Se også, hvordan det hænger sammen med næste trin i skalering før det går galt.
Det skal I lade være med
· At skalere maskinerne op uden målinger.
· At se på gennemsnittet alene.
· At lade udviklerne optimere uden et mål for, hvad der skal blive bedre.
· At teste med små databaser, når kunderne har store.
Det skal I kræve af den eksterne
- ☐ Konkrete svar på, hvilke handlinger der er langsomme, for hvem og hvornår.
- ☐ Målinger, der viser, hvor tiden går.
- ☐ En prioriteret liste over årsager og rettelser.
- ☐ Et overblik over forbrug pr. kunde.
- ☐ En fast måling af de vigtigste handlinger fremover.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hver release er en risiko · Overvågning, vagt og driftshændelser
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
