Karar: Bağlantı havuzu (connection pool) nasıl?
Her veritabanı bağlantısı bellek ve zamanlama maliyeti taşır; kontrolsüz artan bağlantı sayısı sunucuyu yavaşlatır, hatta çökertir. Bağlantı havuzu, az sayıda kalıcı bağlantıyı yeniden kullandırarak bunu çözer. Bu ağaç; havuzun nerede duracağı, hangi mod (session/transaction/statement) ve doğru boyut kararlarında yönlendirir ve serverless ortamlarda harici pooler'ın neden şart olduğunu vurgular.
Uygulama mimarin nasıl bağlanıyor?
Havuz kararı önce mimariyle başlar. Tek bir uzun ömürlü uygulama süreci mi (klasik sunucu), çok sayıda bağımsız süreç/örnek mi (mikroservis, çok pod), yoksa her istekte doğup ölen serverless/Lambda fonksiyonları mı bağlanıyor? Her biri farklı havuz yerleşimi gerektirir.
- Tek/az sayıda uzun ömürlü uygulama süreci
- Çok sayıda süreç/örnek/pod aynı DB'ye bağlanıyor
- Serverless / Lambda / kısa ömürlü fonksiyonlar
- Önce doğru havuz boyutunu nasıl seçerim, onu göster
Ara katman pooler modunu nasıl seçmeli?
Çok sayıda istemci varsa ara katman pooler (PgBouncer, ProxySQL) bağlantı sayısını DB'de düşük tutar. Ama pool mode uygulamanın kullandığı özelliklere bağlıdır: oturuma bağlı durum (prepared statement, geçici tablo, SET, advisory lock'ları, session-level özellikler) kullanıyor musun, yoksa her şey tek transaction içinde mi bitiyor?
- Oturum durumuna bağlıyım (SET, geçici tablo, session prepared statement)
- İşlemler kısa ve bağımsız; oturum durumu tutmuyorum
Öneri: Uygulama içi bağlantı havuzu
Uzun ömürlü tek/az sayıda süreçte, uygulama içi bir havuz kütüphanesi (HikariCP, Go database/sql yerleşik havuzu, .NET connection pooling) çoğu ihtiyacı karşılar. Bağlantılar bir kez açılıp tekrar tekrar kullanılır.
Öneri: Havuz boyutunu doğru hesapla
Havuz ne çok küçük (istekler bekler) ne çok büyük olmalı. Çok bağlantı, CPU'da bağlam değişimi (context switch) ve lock çekişmesi yaratıp verimi düşürür. Boyut, sonsuz büyütülecek bir sayı değil, çekirdek ve I/O temelli küçük bir sayıdır.
Öneri: Session (oturum) pool mode
Session modda bir istemci bağlantısı, oturumu bitene kadar arka uçtaki bir sunucu bağlantısına sabitlenir. Oturum düzeyi durum (SET, geçici tablo, advisory lock, session prepared statement) korunur ama bağlantı paylaşımı en azdır.
Öneri: Transaction pool mode
Transaction modda sunucu bağlantısı yalnızca bir transaction süresince istemciye ödünç verilir; transaction bitince havuza döner. Böylece binlerce istemci, DB'de çok az sayıda gerçek bağlantıyla çalışabilir — en yaygın yüksek ölçek modudur.
Öneri: Serverless için harici pooler şart
Serverless/Lambda fonksiyonları hızla ölçeklenip her örnekte kendi bağlantısını açar; uygulama içi havuz burada işe yaramaz çünkü örnekler kısa ömürlü ve paylaşımsızdır. Aniden yüzlerce/binlerce örnek doğunca DB bağlantı sınırı patlar. Çözüm, DB'nin önünde harici bir bağlantı havuzudur.