// Performance

Find årsagen til en langsom Laravel-applikation

Jeg måler de sider, API-kald eller baggrundsjob, der bremser kunder og drift. I får målinger før og efter samt en forklaring på, hvilke ændringer der hjalp.

Beskriv det langsomme flow

Et konkret sted at undersøge: gentagne databasekald

En oversigt med 50 ordrer kan ende med at hente kunden én gang pr. ordre. Det kaldes et N+1-problem. Eager loading i Laravel kan reducere antallet af kald ved at hente relationerne samlet. Før ændringen måler jeg, om de kald faktisk er årsagen til ventetiden.

Samme side kan være hurtig med få poster og langsom med flere års data. Derfor skal før- og eftermålingen bruge sammenlignelige data og tage højde for cache og samtidige brugere.

// Diagnose

Først et svar på, hvor tiden forsvinder

En langsom Laravel-løsning kan skyldes meget forskellige ting. Derfor tager arbejdet udgangspunkt i de konkrete endpoints, sider eller baggrundsjob, hvor brugere og drift oplever problemet.

Det bliver undersøgt

Langsomme databaseforespørgsler og unødvendigt dataarbejde
Synkrone opgaver, der kan flyttes til køer
Cache, eksterne API-kald og gentaget arbejde
Kode, infrastruktur og overvågning omkring de langsomme flows

Det får I

Svartider og køretider før ændringerne
Prioriteret liste med årsag, konsekvens og anbefaling
Ændringer med automatiske tests af de kritiske flows
Før- og eftermålinger samt dokumentation af ændringerne

Sådan griber jeg målingen an

1
Vælg de vigtigste flows
Vi afgrænser de sider, endpoints eller jobs, der gør mest skade, og aftaler hvad der skal måles.
2
Mål og reproducer
Jeg forsøger at genskabe problemet med sammenlignelige data og belastning. Derefter måler jeg tiden i kode, database og eksterne kald hver for sig.
3
Prioritér efter effekt og risiko
Du får et overblik over hurtige forbedringer, større strukturelle problemer og den anbefalede rækkefølge, før ændringerne udføres.
4
Optimér og mål igen
Ændringer gennemføres i korte iterationer, og samme måling gentages, så resultatet kan vurderes på data.

// Relevant erfaring

Fra 15 sekunder til 2 sekunder på en legacy-platform

Som ansat hos Aller Media fra 2018 til 2020 vedligeholdt jeg mere end ti af Danmarks største mediesites. På Se og Hør arbejdede jeg med indhold, annoncer og billedlevering i en ti år gammel Drupal-applikation. Loadtiden faldt fra 15 til 2 sekunder.

Arbejdet blev udført i Drupal. Det er et eksempel på min erfaring med at optimere eksisterende systemer, ikke en måling af Laravel eller et løfte om samme forbedring hos jer.

Læs casen om Aller og performance →

Godt match, når …

✓I ved, hvilke flows der er langsomme, men ikke hvorfor
✓problemet vokser med trafik eller datamængde
✓I vil forbedre den eksisterende løsning i afgrænsede dele

Før en større omskrivning

Et målebaseret review kan vise, om problemet kan løses målrettet. Ved ældre frameworkversioner bør performancearbejdet ses sammen med en plan for Laravel-opgradering.

// FAQ

Spørgsmål om Laravel-performance

Kan du garantere en bestemt loadtid?

Jeg kan først foreslå et mål, når systemet er målt. Svartiden kan også afhænge af eksterne API’er, trafik og datamængde. Derfor aftaler vi både målet og betingelserne for målingen.

Skal applikationen bygges om?

Ikke nødvendigvis. Performanceproblemer kan ofte løses i afgrænsede dele. Hvis kodebasen også har andre risici, kan arbejdet begynde som en overtagelse med code review.

Arbejder du på produktion?

Produktionsdata og overvågning kan være relevante for målingen, men ændringer udvikles og testes kontrolleret. Adgang og proces aftales efter systemets risikoniveau.

Kan du fortsætte med drift og nye features?

Ja. Efter optimeringen kan samarbejdet fortsætte som løbende Laravel-videreudvikling. Timer og vilkår aftales særskilt.

Hvor oplever brugerne ventetiden?

Send URL eller beskrivelse af det langsomme flow, hvad I allerede har målt, og hvornår problemet opstår. Så kan vi afgrænse den første analyse.

Beskriv performanceproblemet