Havuz ayarı tek servis için değil toplam sistem için yapılır
Bir uygulamada max pool size 20 görmek masum gelebilir. Ama 8 pod, 4 worker process ve 3 ayrı servis varsa toplam potansiyel bağlantı hızla büyür. Veritabanı tarafında görünen sayı tek ayarın değil, tüm mimarinin sonucudur.
Bu nedenle pool hesabı deployment topolojisiyle birlikte yapılmalıdır. Autoscaling varsa en yüksek pod sayısı, job/worker süreçleri ve yönetim araçları da hesaba katılmalıdır.
Toplam bağlantı hesabı
toplam_baglanti = servis_sayisi x pod_sayisi x process_sayisi x max_pool_size Örnek: 3 servis x 6 pod x 2 process x 10 pool = 360 bağlantı
Node.js tarafında havuzu tek yerde tutun
Node.js uygulamalarında sık yapılan hata, her request içinde yeni client veya yeni pool oluşturmaktır. Bu, kısa sürede bağlantı patlamasına yol açar. Pool uygulama yaşam döngüsünde bir kez oluşturulmalı ve paylaşılmalıdır.
Timeout değerleri de bilinçli seçilmelidir. Sonsuz bekleyen sorgu, kullanıcıya iyi deneyim vermez; çok kısa timeout ise geçici yavaşlıkta gereksiz hata üretir.
Node.js pg pool örneği
import { Pool } from 'pg'
export const pool = new Pool({
connectionString: process.env.DATABASE_URL,
max: 10,
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 5000,
})
export async function query(text: string, values: unknown[] = []) {
return pool.query(text, values)
}Go sql.DB zaten havuzdur
Go tarafında database/sql içindeki DB nesnesi tek bağlantı değildir; kendi içinde havuz yönetir. Bu yüzden her işlemde sql.Open çağırmak yerine uygulama başında bir kez açıp ayarları net vermek gerekir.
MaxOpenConns, MaxIdleConns ve ConnMaxLifetime değerleri birlikte düşünülmelidir. Özellikle uzun yaşayan bağlantılar load balancer, proxy veya sertifika yenileme davranışlarıyla çakışabilir.
Go bağlantı havuzu örneği
db, err := sql.Open("pgx", dsn)
if err != nil {
return err
}
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(5)
db.SetConnMaxLifetime(30 * time.Minute)
db.SetConnMaxIdleTime(5 * time.Minute)Java tarafında HikariCP varsayımlarını kontrol edin
Java dünyasında HikariCP güçlü ve yaygın bir seçimdir; ama varsayılan değerler her sistem için doğru değildir. maximumPoolSize, connectionTimeout ve maxLifetime değerleri veritabanı kapasitesi ve uygulama beklentisiyle uyumlu olmalıdır.
Havuz metriklerini izlemek de önemlidir. Active connection sürekli tavana vuruyorsa ya sorgular uzun sürüyor, ya pool küçük, ya da veritabanı yavaşladığı için bağlantılar geri dönmüyordur.
HikariCP ayar fikri
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 5000
idle-timeout: 30000
max-lifetime: 1800000