Будење бази на податоци без мртви конекции

Објавените апликации на Mythex, и нивните бази на податоци, одат во спиење кога никој не ги користи. Кога апликацијата ќе се разбуди, можеше да го задржи првото барање 10–12 секунди, бидејќи се обидуваше да ги повтори конекциите кон базата што умреа додека сè спиеше. Сега на Spring Boot апликациите им даваме поставки за базата што се безбедни по спиење, и му укажуваме на агентот да ги гради апликациите од било кој stack на ист начин. На хостинг платформата, првото барање по будењето падна од 12,7 секунди на 2,3 секунди.

Зошто апликациите и базите спијат

Објавена Mythex апликација работи на машина што се суспендира по неколку минути неактивност, а нејзината база на податоци е serverless Postgres што спие по пет минути неактивност и се буди при следното барање. Тоа е она што ја држи мирна апликацијата евтина: плаќате за она што базата навистина го искористила, а спиечката апликација не троши ништо на compute. За страната на наплатата напишавме во наплата на бази според тоа што навистина го користат.

Уловката е во тоа што двете спијат одделно и не се согласуваат што е конекцијата.

Симптомот: бавна прва посета

Повеќето серверски апликации одржуваат connection pool: мала група отворени конекции кон базата, подготвени однапред, за секое барање да не мора да отвора нова. Тоа е правилен дизајн за апликација што е секогаш вклучена.

Еве што се случува со спиењето:

1. Апликацијата работи, со неколку неактивни конекции во својот pool.
2. Никој не посетува. Машината на апликацијата се суспендира — замрзната, со pool-от непроменет.
3. Базата оди во спиење и го собира својот крај од секоја конекција.
4. Посетител пристигнува. Апликацијата се буди точно така како што била, сè уште држејќи конекции за кои базата веќе не знае.
5. Pool-от дава една од тие конекции. Мора да дознае дека е мртва — така што ќе се обиде и ќе чека — пред да се откаже од неа.

Во Spring Boot апликација, валидирањето на тие мртви конекции го блокираше првото барање околу 10 секунди, пред да падне со „Connection is not available“. За посетителот, страната едноставно visela, па можеби покажуваше грешка.

Зошто Spring апликациите беа најмногу погодени

Spring Boot е популарна Java рамка, а по стандард користи pool за конекции наречен HikariCP. Spring може да го конфигурира тој pool од поставки, вклучувајќи колку неактивни конекции да се држат.

Но Mythex му ја дава базата на секоја апликација како една променлива DATABASE_URL во форма postgresql://user:pass@host/db. Spring не може директно да го чита тој формат. Затоа Spring апликациите изградени на Mythex сами го конструираа својот pool во кодот, со парсирање на тој URL — а pool направен рачно ги игнорира сите spring.datasource.* поставки. Дури и ако некој ги знаеше вистинските поставки за pool, немаше место каде тие да важат.

Поправката, дел 1: поставки што Spring може да ги користи

Кога проектот има база, сега му даваме и променливи на околината што Spring ги чита природно:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME и SPRING_DATASOURCE_PASSWORD, конвертирани од DATABASE_URL (со SSL задолжителен, освен ако URL-то не вели поинаку).
• Поставки за pool што преживуваат спиење:

Бидејќи не се држат неактивни конекции, разбудената апликација отвора една нова конекција наместо да се бори со мртвите.

Кога овие променливи се присутни, Spring самиот го конфигурира pool-от и поставките важат. Што и да проектот го има поставено сам, секогаш важи; ние ја пополнуваме само онаа што недостасува. Апликациите што не се Spring ги игнорираат овие променливи.

Деталот што скоро го направи безначаен

Spring ги мапира променливите на околината на своите поставки по правило што лесно се греши. Поставката minimum-idle мора да се запише како SPRING_DATASOURCE_HIKARI_MINIMUMIDLE — црточките се исфрлени, зборовите се спојуваат. Ако се запише како SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, што изгледа поприродно, се мапира на друга, непостоечка поставка (minimum.idle) и тивко се игнорира.

Тоа е грешка што минува секој преглед и ништо не прави во продукција. Затоа тестот проверува и дека вредностите се поставени и дека ниедна променлива не ја користи формата со долна црта.

Поправката, дел 2: сите други stack-ови

Spring не е единствената рамка со pool, а не можеме однапред да конфигурираме секоја библиотека на секој јазик. Затоа Mythex агентот — AI-то што ја пишува вашата апликација — сега добива постојана инструкција за секој stack: објавените апликации и нивните бази спијат кога се неактивни, па конекција што била отворена може да е мртва при следното барање. Треба да:

• не држи неактивни конекции кон базата отворени, или да ја провери секоја пред употреба,
• да се обиде повторно еднаш при грешка на конекцијата, и
• да ги користи поставките за базата што платформата ги дава во околината, наместо да гради свој pool со парсирање на DATABASE_URL.

Последната точка го затвора јазолот со делот 1: апликација изградена на дадените поставки ја зема конфигурацијата безбедна за спиење автоматски.

Резултатот

Измерено на хостинг платформата на која ги работиме објавените апликации, првото барање по будењето падна од 12,7 секунди на 2,3 секунди.

Што извлековме

• Секој слој што спие мора да се согласува што преживува. Замрзнатата апликација и спиечката база секоја направија разумен избор. Заедно, апликацијата се разбуди држејќи состојба што веќе не важеше.
• Стандардите дизајнирани за секогаш вклучени сервери не се вклопуваат во апликации што се скалираат на нула. Одржувањето конекции топли е добра идеја додека сè околу нив не се излади.
• Дајте им на рамките нивните податоци во нивниот сопствен формат. Еден URL беше едноставен за нас, но ги принуди сите Spring апликации рачно да градат pool што ја игнорира сопствената конфигурација.
• Тестирајте дали поставката е напишана на начинот на кој рамката ја чита. Точна вредност под погрешно име не прави ништо, тивко.

Ако сте нови во тоа како функционираат базите на Mythex, видете ги документацијата за базите и нашето објаснување што е Postgres.