Connection Pool Boyutu: Kaç Bağlantı Yeterli, Ne Zaman Fazla

Connection pool boyutu seçmek, yazılım mühendisliğinde en yanlış hesaplanan karar. Çoğu kişi ya veritabanı bağlantı limitini maksimum yapıyor, ya da rastgele bir sayı seçiyor. İkisi de yanlış.

Pool boyutu şu formüle yaklaşmalı:

Pool Size = (Core Count × 2) + Effective Spindle Count

Bu PostgreSQL ve benzer veritabanları için geçerli. Cores = CPU çekirdeği sayısı, Spindle = disk sayısı (SSD'de 1 olarak hesapla).

Orneksin 8 çekirdekli bir sunucu + 1 SSD için ideal pool: (8 × 2) + 1 = 17 bağlantı.

Bu neden işe yarıyor? Çünkü veritabanı I/O bekleme süresi vardır. Bir thread query çalıştırırken diğer thread başka bir query çalıştırabiliyor. Çok daha fazla bağlantı açarsan, context switching overhead artar ve performans düşer.

3-5 bağlantılı bir pool ile 100 concurrent user'ı karşılayamazsın. İstekler sırada bekler, timeout oluşur. Uygulama hata verir. Veritabanı CPU'su düşük kalırken, bağlantı bekleyen istekler birikir.

En kötüsü: Bağlantı havuzunun kendisi deadlock durumuna girebilir. Tüm bağlantılar meşgul, yeni istek bekler, hiçbir bağlantı serbest olmaz.

500 bağlantı açmak? Veritabanı sunucusu her bağlantı için bellek ayırır. PostgreSQL'de bir bağlantı ~5-10 MB. 500 bağlantı = 2.5-5 GB sadece connection overhead.

Ayrıca, veritabanın lock manager'ı çok sayıda bağlantıyı koordine etmek için daha fazla çalışır. Paradoksal olarak, performans düşer.

Bir de şu var: Uygulamada 500 thread açmak demek, CPU context switching'i artar. İşletim sistemi her millisaniyede thread'ler arasında geçiş yapar. Gerçek parallellik azalır.

1. Başla temellerle: Formülü kullan, oradan başla.
2. Load test yap: Gerçek traffic altında pool'u monitör et. Bağlantı kullanım yüzdesine bak. %80'in üzerindeyse artır, %20'nin altındaysa azalt.
3. Metrik takip et: Query latency, thread pool queue size, active connections. Bunlar artan bir trend gösteriyorsa pool yetersiz.
4. Veritabanı loglarını oku: "too many connections" hatası varsa pool büyüt. Ama bunu birkaç kez gördüğünde değil, tutarlı bir pattern'de yap.
5. Dinamik ayar düşün: Bazı pool kütüphaneleri (HikariCP gibi) otomatik scaling yapabiliyor. Kullan.

100 concurrent user'ı karşılayan bir REST API'nin pool boyutu ne olmalı? Eğer her request 100ms'de bitiyorsa, aynı anda maksimum 10 bağlantı kullanılır. Pool = 15 yeterlidir.

Ama aynı API'de bir endpoint 2 saniye sürüyorsa? Concurrent bağlantı sayısı 100 × (2000 / 100) = 2000'e çıkabilir. Burada pool boyutu arttırmanın yardımı olmaz; endpoint'i optimize etmen gerekir.

Connection pool boyutu veritabanı bağlantı limitine göre değil, uygulamanın I/O karakteristiğine göre belirlenmelidir. Formülü başlangıç olarak kullan, load test'ten sonra ince ayar yap. Çoğu sorun pool boyutundan değil, kötü query veya bağlantı sızıntısından kaynaklanır.