Å vekke databaser uten døde forbindelser

Publiserte apper på Mythex, og databasene deres, går i dvale når ingen bruker dem. Når en app våknet, kunne den holde første forespørsel i 10–12 sekunder, fordi den prøvde å gjenbruke databaseforbindelser som døde mens alt sov. Nå gir vi Spring Boot-apper databaseinnstillinger som tåler dvale, og vi ber agenten bygge apper i alle stacker på samme måte. På hostingplattformen gikk første forespørsel etter en vekking fra 12,7 sekunder til 2,3 sekunder.

Hvorfor apper og databaser går i dvale

En publisert Mythex-app kjører på en maskin som suspenderes etter noen få minutter uten aktivitet. Databasen er serverløs Postgres, som går i dvale etter fem minutter uten aktivitet og våkner ved neste forespørsel. Det er det som holder en rolig app billig: du betaler for det databasen faktisk brukte, og en app i dvale bruker ingenting på beregning. Vi skrev om faktureringssiden i fakturering av databaser etter hva de faktisk bruker.

Fellen er at de to går i dvale hver for seg, og de er ikke enige om hva en forbindelse er.

Symptomet: et tregt første besøk

De fleste serverapper holder en forbindelsespool: et lite antall åpne databaseforbindelser som holdes klare, slik at hver forespørsel ikke må betale kostnaden ved å åpne en ny. Det er riktig design for en app som alltid er på.

Slik går det med dvale:

1. Appen kjører, med noen få inaktive forbindelser i poolen.
2. Ingen besøker den. Appens maskin suspenderes, frosset med poolen intakt.
3. Databasen går i dvale og sletter sin ende av alle forbindelser.
4. En besøkende kommer. Appen våkner akkurat slik den var, og holder fortsatt forbindelser databasen ikke lenger kjenner til.
5. Poolen gir ut en av disse forbindelsene. Den må finne ut at den er død, ved å prøve den og vente, før den gir opp.

I en Spring Boot-app blokkerte validering av de døde forbindelsene første forespørsel i rundt 10 sekunder, før den til slutt feilet med «Connection is not available». For den besøkende hang nettstedet bare, og kanskje viste det en feil til slutt.

Hvorfor Spring-apper fikk det verst

Spring Boot er et populært Java-rammeverk, og det bruker som standard en forbindelsespool som heter HikariCP. Spring kan konfigurere poolen fra innstillinger, inkludert hvor mange inaktive forbindelser som skal holdes.

Men Mythex gir hver app databasen som én enkelt DATABASE_URL på formen postgresql://user:pass@host/db. Spring kan ikke lese det formatet direkte. Så Spring-apper bygget på Mythex konstruerte sin egen pool i kode ved å parse den URL-en. En pool bygget for hånd ignorerer alle Springs spring.datasource.*-innstillinger. Selv om noen kjente de riktige poolinnstillingene, fantes det ingen steder der de kunne tre i kraft.

Løsningen, del 1: innstillinger Spring kan bruke

Når et prosjekt har en database, gir vi det nå også miljøvariabler som Spring leser direkte:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME og SPRING_DATASOURCE_PASSWORD, konvertert fra DATABASE_URL (med SSL påkrevd, med mindre URL-en sier noe annet).
• Poolinnstillinger som tåler dvale:

Uten inaktive forbindelser holdt åpne, åpner en vekket app én ny forbindelse i stedet for å vade gjennom døde.

Når disse variablene finnes, konfigurerer Spring poolen selv, og innstillingene gjelder. Det prosjektet selv har satt, vinner alltid; vi fyller bare inn det som mangler. Apper som ikke er Spring, ignorerer disse variablene.

Detaljen som nesten gjorde at det ikke virket

Spring kobler miljøvariabler til innstillingene sine etter en regel som er lett å gjøre feil på. Innstillingen minimum-idle må skrives som SPRING_DATASOURCE_HIKARI_MINIMUMIDLE, med bindestreker fjernet og ordene skrevet sammen. Skriver du den som SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, som virker mer naturlig, peker den på en annen, ikke-eksisterende innstilling (minimum.idle) og ignoreres stille.

Det er den typen feil som passerer alle review-runder og ikke gjør noe i produksjon. Derfor sjekker en test både at verdiene er satt, og at ingen variabel bruker den understrekede formen.

Løsningen, del 2: alle andre stacker

Spring er ikke det eneste rammeverket med en pool, og vi kan ikke forhåndskonfigurere hvert bibliotek i hvert språk. Så Mythex-agenten, AI-en som skriver appen din, får nå en fast instruks for alle stacker: publiserte apper og databasene deres går i dvale når de er inaktive, så en forbindelse som holdes åpen, kan være død ved neste forespørsel. Agenten skal:

• ikke holde noen inaktive databaseforbindelser åpne, eller sjekke hver enkelt før bruk,
• forsøke én gang på nytt ved en forbindelsesfeil, og
• bruke databaseinnstillingene plattformen gir i miljøet, i stedet for å bygge sin egen pool ved å parse DATABASE_URL.

Det siste punktet knytter sammen del 1 og del 2: en app bygget på innstillingene plattformen gir, plukker opp den dvaletrygge konfigurasjonen automatisk.

Resultatet

Målt på hostingplattformen vi kjører publiserte apper på, gikk første forespørsel etter en vekking fra 12,7 sekunder til 2,3 sekunder.

Det vi tok med oss

• Alle lag som går i dvale, må være enige om hva som overlever. En frosset app og en sovende database tok hver sin fornuftige beslutning. Sammen våknet appen med tilstand som ikke lenger var sann.
• Standardinnstillinger laget for servere som alltid er på, passer ikke apper som skaleres til null. Å holde forbindelser varme er en god idé, helt til alt rundt dem blir kaldt.
• Gi rammeverk dataene i deres eget format. Én URL var enkelt for oss, men den tvang hver Spring-app til å håndlage en pool som ignorerte sin egen konfigurasjon.
• Test at en innstilling er stavet slik rammeverket leser den. En riktig verdi under feil navn gjør ingenting, stille.

Hvis du er ny til hvordan databaser fungerer på Mythex, se databasedokumentasjonen og vår forklaring på hva Postgres er.