Få mest ud af MySQL i Laravel

  Skrevet af: Kristian Just     29-09-2022     Skrevet i: PHP, Webdesign

Laravel er et ekstremt stabilt, hurtigt og moderne PHP framework. Systemet indeholder alle de basis funktioner, som du derved ikke behøver bygge selv. Heriblandt authentication system, logging system, routing og selvfølgelig et database lag.

Databaser og Laravel

I Laravel er der som standard understøttelse af MariaDB, MySQL, SQLite, PostgreSQL, SQL Server.

Det er nemt at opsætte MySQL databaseforbindelsen. Alt der skal til er at ændre miljøvariablerne i filen `.env` eller evt. direkte i filen `config/database.php`.

Husk derudover at sætte variablen DB_CONNECTION til ‘mysql’.

Hvis du din databaseserver kører og der er angivet korrekte credentials, så vil der allerede nu være forbindelse mellem applikaitonen og databasen.

MySQL er en moden database, som kan håndtere millioner – ja, endda milliarder – af rækker med en fornuftig læse- og skrivehastighed under de rette forudsætninger.

Da den er relationelt opbygget passer den rigtigt godt til webapplikationer, hvor der typisk en enhed, som har relationer til andre enheder (fx en bruger, der har en relation til en organisation, og en bruger, der har en relation til ordrer. Ordrer der har relation til betalinger osv.).

Performance fælde #1: N+1

Når du kalder din database, er der er en del overhead.

Det betyder, at det tager tid at etablere forbindelsen til databaseserveren m.v. Derfor er der en del at spare, ved at få så meget data ud på samme tid som muligt. Dvs. med så få forbindelser til databasen som muligt.

Eksempel

Du har en brugerliste og udfor hver bruger står der, hvor mange aktive “projekter” de har i din applikation.

Hvis du i din første forespørgsel, der trækker listen med brugere, ikke udtrækker antal projekter, så vil du blive nødt til at hente antal projekter for hver eneste bruger efterfølgende.

Du får dermed en MySQL forespørgsel ind i din `foreach`.

Har du 100 brugere, så vil du have 1 forespørgsel til at hente brugerlisten og 100 forespørgsler, der henter antal projekter. Det giver 101 gange forbindelsesoverhead.

Løsningen er at eager loade antal projekter for alle brugere.

Nu har du dermed 1 forespørgsel til at hente brugerlisten og 1 forespørgsel til at hente antal projekter for alle brugere. Det giver 2 gange forbindelsesoverhead.

Når antallet af brugere stiger, vil du ikke skabe flere database forespørgsler.

Performance fælde #2: Lange forespørgsler

Nu har du styr på antallet af forespørgsler.

Det næste er, om de forespørgsler du laver, kan hente eller skrive dataene på en effektiv måde.

Den nemmeste måde at overvåge dette på er ved at aktivere “slow query log” i MySQL serveren.

Slow query loggen afslører, om der bliver kørt forespørgsler, som tager over x antal sekunder at eksekvere.

Der vil typisk være tale om få forespørgsler, som tager længere tid end forventet.

Det er derfor oftest en overskuelig opgave at rette disse få forespørgsler og igen have en applikation, som kan yde det den skal.

Performance fælde #3: Strukturen er forkert

Der er mange måder at strukturere en database på.

Der er branche konsensus omkring, at det i relationalle databaser giver mening at normalisere dataene.

På den måde ligger data kun én gang.

Forsøger du i stedet at bruge databasen som en column store, hvor alt data, der skal bruges, ligger på samme række, vil du opleve, at databasen fylder markant mere end den burde. MySQL kommer heller ikke til sin ret, hvis man ikke anvender på den tiltænkte måde. Andre databaser er bedre til at håndtere kolonnebaseret data. Det er analytiske databaser, som fx SingleStore og ClickHouse, bedre til at håndtere.

Stukturen i din database er fundamentet for meget af din applikationslogik, og det har betydning for din tekniske gæld og udvikler effektivitet. Vælg derfor din Laravel udvikler med omhu, for at være sikker på at få det bedste udgangspunkt for fremtiden.

Performance fælde #4: Forkert størrelse server

Du kan optimere vildt meget, men på et tidspunkt bliver du nødt til at se på, om den MySQL server, du har opstillet, kan følge med.

Med x antal rå data, der skal indsættes eller læses, så er der en øvre fysisk grænse for, hvad serveren kan levere.

Har du MySQL serveren hosted i et datacenter/cloud, vil der sandsynligvis være mulighed for at se på nogle metrikker, som bliver overvåget automatisk.

Fx kan der undersøges, om der bliver ramt en øvre grænse indenfor CPU brug, hukommelsesforbrug eller I/O til disk (IOPS).

Hoster du selv MySQL serveren, vil linux værktøjer som htop og iotop være behjælpelige.

Afslutning

I ovenstående håber jeg, at du har fået et indblik i nogle af de lavest hængende frugter indenfor MySQL og Laravel optimering.