Datubāzes pamošana bez mirušiem savienojumiem

Publicētās Mythex lietotnes un to datubāzes iet gulēt, kad tās neviens neizmanto. Kad lietotne pamodās, tā varēja turēt pirmo pieprasījumu 10–12 sekundes, jo mēģināja izmantot datubāzes savienojumus, kas bija nomiruši, kamēr viss gulēja. Tagad Spring Boot lietotnēm dodam datubāzes iestatījumus, kas ir droši pēc miega, un aģentam liekam veidot jebkura steka lietotnes tādā pašā veidā. Mitināšanas platformā pirmais pieprasījums pēc pamošanās samazinājās no 12,7 sekundēm līdz 2,3 sekundēm.

Kāpēc lietotnes un datubāzes guļ

Publicēta Mythex lietotne darbojas mašīnā, kas pēc dažām dīkstāves minūtēm apturas, un tās datubāze ir bezserveru Postgres, kas guļ pēc piecām dīkstāves minūtēm un pamostas ar nākamo vaicājumu. Tas ir, kas notur klusu lietotni lētu: maksā par to, ko datubāze faktiski izmantoja, un guļoša lietotne neko netērē skaitļošanai. Par norēķinu pusi esam rakstījuši rakstā datubāzu norēķins pēc tā, ko tās faktiski izmanto.

Noķeris ir tāds, ka abi guļ atsevišķi un nepiekrīt par to, kas ir savienojums.

Simptoms: lēns pirmais apmeklējums

Lielākā daļa servera lietotņu notur savienojumu pūlu: nedaudzus atvērtus datubāzes savienojumus, kas gatavi, lai katrs pieprasījums nemaksātu par jauna savienojuma atvēršanu. Tas ir pareizs dizains lietotnei, kas vienmēr ir ieslēgta.

Šeit notiek, kad tā guļ:

1. Lietotne darbojas, ar dažiem dīkstāves savienojumiem savā pūlā.
2. Neviens neapmeklē. Lietotnes mašīna apstājas, sasaldēta ar savu pūlu neskartu.
3. Datubāze iet gulēt un atlaiž savu galu no katra savienojuma.
4. Apmeklētājs ierodas. Lietotne pamostas tieši tāda, kāda bija, joprojām turot savienojumus, ko datubāze vairs nepazīst.
5. Pūls izsniedz vienu no šiem savienojumiem. Tam jāuzzina, ka tas ir miris, to mēģinot un gaidot, pirms atmet.

Spring Boot lietotnē šo mirušo savienojumu validācija bloķēja pirmo pieprasījumu apmēram uz 10 sekundēm, pirms tas neizdevās ar „Connection is not available“. Apmeklētājam vietne vienkārši karājās, un tad varbūt parādīja kļūdu.

Kāpēc Spring lietotnes cieta visvairāk

Spring Boot ir populārs Java ietvars, un pēc noklusējuma tas izmanto savienojumu pūlu HikariCP. Spring var konfigurēt šo pūlu no iestatījumiem, arī to, cik dīkstāves savienojumus turēt.

Bet Mythex katrai lietotnei datubāzi dod kā vienu DATABASE_URL formā postgresql://user:pass@host/db. Spring šo formātu tieši nelasa. Tāpēc Spring lietotnes, kas veidotas Mythex, paši veidoja savu pūlu kodā, parsējot šo URL, un pūls, kas izveidots ar rokām, ignorē visus Spring spring.datasource.* iestatījumus. Pat ja kāds zinātu pareizos pūla iestatījumus, nebija vietas, kur tie stātos spēkā.

Labojums, 1. daļa: iestatījumi, ko Spring var izmantot

Kad projektam ir datubāze, tam tagad dodam arī vides mainīgos, ko Spring lasa dabiski:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME un SPRING_DATASOURCE_PASSWORD, pārveidoti no DATABASE_URL (ar prasīto SSL, ja vien URL nesaka citādi).
• Pūla iestatījumi, kas pārdzīvo miegu:

Bez turēta dīkstāves savienojuma pamodusies lietotne atver vienu jaunu savienojumu, nevis brienas cauri mirušajiem.

Kad šie mainīgie ir klāt, Spring pats konfigurē pūlu, un iestatījumi stājas spēkā. Ko projekts pats iestatījis, vienmēr uzvar; mēs aizpildām tikai to, kas trūkst. Ne-Spring lietotnes šos mainīgos ignorē.

Detaļa, kas gandrīz padarīja to bezjēdzīgu

Spring kartē vides mainīgos uz saviem iestatījumiem pēc noteikuma, ko ir viegli sajaukt. Iestatījums minimum-idle jāraksta kā SPRING_DATASOURCE_HIKARI_MINIMUMIDLE: domuzīmes nav, vārdi saliekti kopā. Ja to rakstām kā SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, kas izskatās dabiskāk, tas kartējas uz citu, neeksistējošu iestatījumu (minimum.idle) un tiek klusi ignorēts.

Tāda kļūda iztur katru pārskatīšanu un neko nedara ražošanā. Tāpēc tests pārbauda gan to, ka vērtības ir iestatītas, gan to, ka neviens mainīgais neizmanto ar pasvītrām atdalīto formu.

Labojums, 2. daļa: visi pārējie steki

Spring nav vienīgais ietvars ar pūlu, un mēs nevaram iepriekš konfigurēt katru bibliotēku katrā valodā. Tāpēc Mythex aģents, kas raksta tavu lietotni, tagad saņem pastāvīgu norādi katram stekam: publicētas lietotnes un to datubāzes guļ, kad ir dīkstāvē, tāpēc savienojums, kas tika turēts atvērts, nākamajā pieprasījumā var būt miris. Tam vajadzētu:

• nevienu dīkstāves datubāzes savienojumu neturēt atvērtu vai pārbaudīt katru pirms lietošanas,
• vienreiz mēģināt atkārtoti pie savienojuma kļūdas, un
• izmantot datubāzes iestatījumus, ko platforma nodrošina vidē, nevis veidot savu pūlu, parsējot DATABASE_URL.

Pēdējais punkts noslēdz cilpu ar 1. daļu: lietotne, kas veidota uz nodrošinātajiem iestatījumiem, automātiski saņem miegam drošo konfigurāciju.

Rezultāts

Mērīts platformā, kurā mēs mitinām publicētās lietotnes, pirmais pieprasījums pēc pamošanās samazinājās no 12,7 sekundēm līdz 2,3 sekundēm.

Ko no tā guvām

• Katrs slāņis, kas guļ, jāvienojas par to, kas pārdzīvo. Sasaldēta lietotne un guļoša datubāze katra izdarīja saprātīgu izvēli. Kopā lietotne pamodās ar stāvokli, kas vairs nebija patiess.
• Noklusējumi, kas izstrādāti serveriem, kas vienmēr ieslēgti, neder lietotnēm, kas mērogojas līdz nullei. Savienojumu uzturēšana silta ir laba ideja, kamēr viss ap tiem atdziest.
• Dod ietvariem to datu formātā, ko tie lasa. Viens URL mums bija vienkāršs, bet piespieda katru Spring lietotni ar rokām veidot pūlu, kas ignorēja tās pašas konfigurāciju.
• Pārbaudi, ka iestatījums ir uzrakstīts tā, kā ietvars to lasa. Pareiza vērtība nepareizā nosaukumā nedara neko, klusi.

Ja esi jauns tam, kā datubāzes darbojas Mythex, skat. datubāzes dokumentāciju un mūsu skaidrojumu par ko ir Postgres.