Connection Pool Nedir?
Her veritabanı isteğinde sıfırdan bir bağlantı açmak maliyetlidir: TCP el sıkışması, kimlik doğrulama, oturum kurulumu... Bunların her seferinde tekrarlanması gecikmeye ve kaynak israfına yol açar.
Connection Pool bu sorunu çözer: Önceden belirli sayıda veritabanı bağlantısı açılır ve bir havuzda tutulur. Gelen istekler bu havuzdan bağlantı alır, işini bitirince bağlantıyı iade eder. Bağlantı tekrar tekrar açılıp kapanmaz; yeniden kullanılır.
- ✓Daha hızlı yanıt süreleri — bağlantı kurulum maliyeti ortadan kalkar
- ✓Daha az kaynak tüketimi — veritabanı sunucusu gereksiz yük taşımaz
- ✓Daha stabil entegrasyon — ani trafik artışlarında sistem çökmez, bekletir
MuleSoft Database Connector'da Nasıl Çalışır?
MuleSoft'un Database Connector'ı arka planda HikariCP adlı yüksek performanslı bir JDBC bağlantı havuzu kütüphanesi kullanır. Anypoint Studio'da bir veritabanı bağlantısı (Database Config) tanımladığınızda, aslında bu havuzun parametrelerini yapılandırıyorsunuzdur.
Bu parametrelere ulaşmak için: Global Elements → Database Config → Advanced sekmesi → Pooling Profile yolunu izleyin.
Flow bağlantı ister → havuzdan hazır bağlantı verilir (TCP el sıkışması olmadan) → iş bitince bağlantı iade edilir → bir sonraki flow kullanabilir. Havuz doluysa yeni istekler max-wait (5 sn) bekler, timeout aşılırsa hata fırlatılır.
Parametreler Ne Anlama Gelir?
Tipik bir yapılandırmayı parametre parametre inceleyelim:
| Parametre | Değer | Açıklama |
|---|---|---|
| Max pool size | 8 | Aynı anda açık olabilecek maksimum bağlantı sayısı. Bu sınıra ulaşılınca yeni istekler beklemeye alınır. |
| Min pool size | 2 | Havuzda her zaman hazır bekleyecek minimum bağlantı sayısı. Düşük trafikte bile 2 bağlantı açık tutulur. |
| Acquire increment | 2 | Havuz dolduğunda kaçar kaçar yeni bağlantı açılacağı. Ani artışlarda 2'şer 2'şer genişler. |
| Max wait | 5 sn | Bağlantı bulunamazsa beklenecek maksimum süre. Bu süre aşılırsa uygulama hata fırlatır. |
| Max idle time | 300 sn | Kullanılmayan bir bağlantının havuzda tutulma süresi. 5 dakika sonra kapatılır, kaynak israfı önlenir. |
| Max statements | 50 | Önbellekte tutulan hazır SQL ifadesi sayısı. Aynı sorguların tekrar derlenmesini önler. |
Yanlış Yapılandırmanın Yarattığı Sorunlar
Connection pool doğru ayarlanmadığında iki uç senaryoyla karşılaşılır:
Havuz çok küçük ayarlandığında:
- ✓Yüksek trafikte bağlantı bekleyen istekler birikir, flow'larda gecikme yaşanır
- ✓Max wait süresi aşılınca timeout hatası fırlatılır — bu doğrudan 500 hatası olarak yansıyabilir
- ✓Aynı DB Config'i kullanan birden fazla flow varsa (insert + update gibi) rekabet durumu ortaya çıkar
Havuz çok büyük ayarlandığında:
- ✓Veritabanı sunucusu gereksiz yere fazla bağlantı taşır, max_connections sınırına ulaşılabilir
- ✓Diğer uygulama ve servislerin DB erişimi engellenebilir
- ✓Bellek ve işlemci kaynakları boşa harcanır
Bağlantı Sızıntısı (Connection Leak) Riski
Bir bağlantı alındıktan sonra işlem hata verirse ve bağlantı düzgün iade edilmezse, havuza geri dönmez. Zamanla havuz tükenir ve uygulama yeni bağlantı alamaz hale gelir. Buna connection leak denir.
MuleSoft bu riski büyük ölçüde yönetir; Database Connector işlem tamamlandığında veya hata alındığında bağlantıyı otomatik iade eder. Ancak özellikle Try-Catch blokları ve özel transaction yönetimi olan senaryolarda bu davranışın dikkatli test edilmesi gerekir.
Önerilen Yaklaşım
Her projenin ihtiyacı farklıdır, ancak genel bir başlangıç noktası olarak şu yaklaşım önerilir:
- ✓Min Pool Size: 2–5, Max Pool Size: 10–20 ile başlayın; yük testleriyle ince ayar yapın
- ✓Veritabanı tarafındaki max_connections değerini öğrenin ve tüm uygulamaların toplamını bu sınırın altında tutun
- ✓Dev, test ve prod ortamları için pool boyutlarını ayrı ayrı tanımlayın — properties dosyası veya Anypoint Runtime Manager üzerinden yönetin
- ✓Aynı Database Config'i birden fazla flow paylaşıyorsa (örneğin insert + update) bunu pool boyutunu belirlerken hesaba katın
- ✓Kibana veya Anypoint Monitoring ile bağlantı kullanımını düzenli olarak izleyin
