Connection Pooling: Proč může být důležité pro výkon databáze

Databázové spojení vzniká při každé komunikaci aplikace s databází. Pokud ho aplikace po každém požadavku zavře a znovu otevírá, zbytečně opakuje práci a může zvyšovat zátěž serveru. Connection pooling tomu předchází. Hotová spojení uchovává a podle potřeby je půjčuje dalším požadavkům. Sám o sobě ale nezrychlí pomalý SQL dotaz a špatně nastavený pool může databázi naopak přetížit.

Co je databázové spojení

Databázové spojení je komunikační kanál mezi aplikací a databázovým serverem. Aplikace přes něj posílá požadavky, například na načtení nebo uložení dat, a databáze jí vrací výsledky.

Když návštěvník otevře stránku, může se například stát toto:

•     Aplikace požádá o spojení s databází. Použije k tomu adresu serveru a přihlašovací údaje.
•     Databázový server ověří požadavek a připraví spojení pro komunikaci.
•     Aplikace odešle SQL dotaz, třeba žádost o seznam článků nebo detail objednávky.
•     Databáze dotaz zpracuje a pošle aplikaci výsledek.
•     Aplikace spojení ukončí nebo vrátí do poolu, aby ho mohl využít další požadavek.

Vytvoření spojení představuje práci navíc. Server musí požadavek přijmout, ověřit a vyhradit pro něj potřebné prostředky. Pokud aplikace spojení opakovaně zavírá a znovu navazuje, tuto přípravu provádí stále dokola. Connection pooling umožňuje hotová spojení znovu používat.

Jak funguje connection pool

Connection pool je zásobník již navázaných spojení. Když aplikace potřebuje přístup k databázi, požádá pool o volné spojení. Po dokončení práce ho vrátí zpět, místo aby ho zavřela. Další požadavek pak může využít stejné spojení.

Pool obvykle stanovuje také maximální počet spojení, která může aplikace otevřít. Pokud jsou všechna právě využitá, další požadavek čeká, dokud se některé neuvolní. Například knihovna HikariCP popisuje maximumPoolSize jako horní limit spojení do databáze. Při jeho dosažení a nedostatku volných spojení čeká aplikace po nastavenou dobu na uvolnění dalšího.

Pooling může být součástí aplikace, například v podobě knihovny pro správu databázových spojení. U PostgreSQL zajišťuje správu spojení mezi aplikací a databází také samostatná mezivrstva, například PgBouncer. Ten umožňuje, aby více klientských spojení sdílelo menší počet spojení přímo do databáze.

Jaký režim pooling používá

U externího pooleru záleží na tom, kdy se spojení do databáze uvolní pro dalšího klienta. PgBouncer nabízí několik režimů:

•   Session pooling – spojení se vrátí do poolu až po odpojení klienta.
•   Transaction pooling – spojení se vrátí po dokončení transakce.
•   Statement pooling – spojení se uvolní po dokončení jednotlivého dotazu; tento režim nepovoluje transakce rozložené do více příkazů.

Transakční režim může umožnit obsloužit mnoho klientů menším počtem spojení do PostgreSQL. Vyžaduje však ověřit, zda aplikace nespoléhá na stav konkrétního spojení mezi transakcemi. Režim statement pooling zase není vhodný pro všechny aplikace, protože nepodporuje transakce složené z více příkazů.

Kdy může pooling pomoct

Connection pooling se hodí hlavně tehdy, když aplikace obsluhuje mnoho krátkých požadavků nebo často navazuje a ukončuje databázová spojení. Opakované použití otevřených spojení může omezit čekání při jejich vytváření. Pool zároveň pomáhá řídit počet spojení, která aplikace používá: 

• Omezuje režii při navazování spojení – aplikace může použít již otevřené spojení místo toho, aby pro každý požadavek vytvářela nové.
• Pomáhá zvládat nárazový provoz – připravená spojení mohou být k dispozici, když se po klidnějším období zvýší počet požadavků.
• Řídí souběžný přístup k databázi – pool nastaví horní limit počtu spojení, která aplikace používá. Příliš mnoho současně aktivních požadavků totiž může zvýšit soupeření o procesor, paměť nebo interní zámky.
• Může ulevit databázi při vysokém počtu klientů – dokumentace MySQL upozorňuje, že při modelu jednoho vlákna na klientské spojení může s rostoucím počtem klientů výkon klesat. Jedním z důvodů je režie přepínání mezi vlákny; MySQL proto nabízí také thread pool, který řídí počet vláken zpracovávajících příkazy.
• Nezrychlí samotné SQL dotazy – pooling nevyřeší pomalý dotaz, chybějící index ani načítání zbytečně velkého množství dat. Může zkrátit čekání spojené s připojením, ale ne dobu, kterou databáze potřebuje ke zpracování dotazu.
• Vyžaduje sledování čekajících požadavků – pokud jsou všechna spojení obsazená, další požadavky čekají na uvolnění některého z nich. Dlouhé čekání může znamenat příliš malý pool, ale také to, že databáze nestíhá zpracovávat příchozí práci.

Aby pooling skutečně pomáhal, je potřeba nastavit jeho velikost podle zátěže aplikace a možností databáze. Sledujte, kolik spojení je právě využitých a jak dlouho požadavky čekají na volné. Pokud se čekání prodlužuje, prověřte také vytížení databáze a rychlost dotazů. Samotné zvětšení poolu nemusí problém vyřešit.

Jak pool správně nastavit

Univerzální ideální velikost poolu neexistuje. Záleží na kapacitě databáze, počtu instancí aplikace, charakteru dotazů i na tom, kolik spojení potřebují další služby. Pokud má například každá instance aplikace vlastní pool, je třeba počítat se součtem maximálních velikostí všech poolů. K tomu je vhodné nechat rezervu pro administraci a další provoz.

Příliš malý pool může způsobit dlouhé čekání aplikace na volné spojení. Příliš velký pool zase může otevřít do databáze více spojení, než je schopná efektivně zpracovávat. Navýšení limitu proto nemusí vyřešit pomalé odezvy. Může jen přesunout problém na databázový server.

Při ladění sledujte zejména:

•     kolik spojení je právě aktivních a kolik jich čeká v poolu,
•     jak dlouho aplikace čeká na získání spojení,
•     kolik spojení databáze skutečně obsluhuje,
•     zda je vytížení databáze způsobené dotazy, nebo samotným počtem spojení,
•     jak se mění odezva při běžné zátěži i během špičky.

Pooly také potřebují správně řešit zastaralá spojení. Databáze nebo síťová infrastruktura je může po určité době ukončit. Knihovna HikariCP proto mimo jiné umožňuje nastavit maximální životnost spojení a doporučuje ji sladit s limity databáze a infrastruktury.

Pooling je součást výkonu, ne zkratka

Connection pooling může omezit opakované navazování spojení a pomoci udržet souběžný přístup k databázi v rozumných mezích. Největší přínos má tam, kde aplikace často vytváří krátkodobá spojení nebo obsluhuje mnoho klientů.

Výsledek ale závisí na správném nastavení a měření. Pokud aplikace čeká na volné spojení, je potřeba zjistit, zda je pool příliš malý, nebo zda databázi zahlcuje příliš mnoho práce. A pokud jsou pomalé samotné dotazy, je třeba hledat jejich příčinu v SQL, indexech, datech či infrastruktuře. Pool může pomoci efektivněji využít databázová spojení, ale nenahradí optimalizaci databáze ani aplikace.