SqlClient Pool V2 Paralel Bağlantı Açmayı Hızlandırıyor
Microsoft.Data.SqlClient kullanan uygulamalarda aynı anda çok sayıda istek bağlantı beklediğinde uygulama açılışı gecikiyor, gecikme büyüyordu. Yeni bağlantı havuzu (Pool V2) yeni bağlantıları eşzamanlı kurarak tam bu darboğazı hedefliyor. Aşağıda Pool V2’nin ne değiştirdiği, ölçülen cold-start sonuçları, bilinen asenkron G/Ç sınırlaması ve tek satırlık etkinleştirme adımı var.
Eski havuzdaki darboğaz neydi?
Klasik (legacy) bağlantı havuzunda bir havuz içinde aynı anda yalnızca tek bir yeni bağlantı açılabiliyordu. Havuzun büyümesi gereken anlarda istekler sıraya giriyor, bu da en çok şu senaryolarda hissediliyordu:
- Uygulama açılışında birkaç farklı metadata sorgusunun aynı anda çalışması,
- Sessiz bir dönemin ardından gelen ani trafik artışları.
Geliştiriciler bu sınırı aşmak için geçici çözümlere başvuruyordu: Min Pool Size değerini artırıp kapasiteyi önceden rezerve etmek ya da havuzlamayı tamamen kapatmak. Pool V2 ile bu tür çözümlere gerek kalmıyor.
Pool V2 nasıl çalışıyor?
Tasarım asenkron iş yüklerini merkeze alıyor. Çekirdekte, ayrılmış arka plan iş parçacıklarına dayanmak yerine System.Threading.Channels kullanılıyor; birinci sınıf asenkron desteğe sahip üretici-tüketici veri yapılarından oluşan bir küme. Microsoft’un aktardığına göre bu yaklaşım, çok sayıda farklı veritabanına bağlanan uygulamalarda iş parçacığı yönetimi yükünü azaltabiliyor. Ekip, bu havuzlama tasarımının önünü açtığı için Npgsql sürücü ekibine teşekkür ediyor.
Aynı anda birden fazla istek yeni bağlantı talep ettiğinde havuz artık bağlantıları eşzamanlı kurabiliyor ve daha hızlı yanıt veriyor. Fark kabaca bu.
Ölçülen cold-start sonuçları
Microsoft, eski havuzla Pool V2’nin soğuk başlangıçta (cold start) belirli sayıda bağlantıyı ne kadar sürede kurabildiğini ölçtü. Her testte havuz temizlendi, ardından eşzamanlı çağıranların aynı sayıda bağlantıyı açıp tüm açma işlemleri tamamlanana kadar tutması süreölçüme alındı.
Ölçülen süreye bağlantı oluşturma, senkronizasyon ve bağlantıların havuza iadesi dahil; havuz temizleme ile test kurulumu hariç tutuldu. Sonuçlar tek bir bağlantı açma işleminin gecikmesini değil, işlemin tamamının ortalama süresini temsil ediyor. Testler Max Pool Size=200 ayarıyla 10, 25, 50 ve 100 eşzamanlı çağıranla yapıldı; ağ değişkenliğini azaltmak için SQL Server benchmark ile aynı makinede çalıştırıldı.
Senkron ve asenkron sonuçlar
- Senkron: Linux üzerinde 100 eşzamanlı çağıranla Pool V2, ortalama cold-start benchmark süresini 630,1 ms’den 117,5 ms’ye indirdi, yani 5,4 kat hızlanma. Senkron çağıranlar
SqlConnection.Open()ile ayrılmış iş parçacıkları kullanıyor. - Asenkron: Aynı koşullarda ortalama süre 604,1 ms’den 92,0 ms’ye düştü, 6,6 kat hızlanma. Asenkron çağıranlar
SqlConnection.OpenAsync()ile task kullanıyor.
Her iki senaryoda da çağıranlar tüm açma işlemleri tamamlanana kadar bağlantılarını tutuyor ve düşük süre daha iyi anlamına geliyor.
Bu benchmark’lar yalnızca soğuk başlangıçtaki bağlantı kurulumunu ve koordinasyonu ölçüyor; sınır da burası. SQL sorgu yürütmesi ya da ısınmış bir havuzdaki bağlantı yeniden kullanımı kapsam dışında. Sonuçlar iş yüküne ve ağ gecikmesine göre değişir.
Test ortamı
- Linux: 16 çekirdek / 32 mantıksal CPU Intel Xeon Platinum 8168 sanal makinede Ubuntu 22.04.5 LTS; SQL Server 2022 Developer CU26,.NET 9.0.19, BenchmarkDotNet 0.15.8.
- Windows: Aynı donanım profilinde Windows Server 2022 Datacenter Azure Edition; SQL Server 2025 Enterprise Evaluation RTM,.NET 9.0.19, BenchmarkDotNet 0.15.8.
Benchmark’ın tam kaynak kodu dotnet/SqlClient GitHub deposunda yayımlanıyor.
Bilinen asenkron G/Ç sınırlaması
SqlConnection.OpenAsync() henüz her bir ağ çağrısına kadar tam anlamıyla asenkron değil. Pool V2 şimdilik iş öğelerini yönetilen thread pool iş parçacıklarına kuyruğa alıyor, bu iş parçacıkları da senkron ağ çağrıları gerçekleştiriyor. Söz konusu ağ çağrılarında gecikme yüksekse yönetilen thread pool üzerindeki baskı artabiliyor; ek iş parçacıklarının devreye girmesini beklemek son kullanıcı tarafında gecikmeye yol açabiliyor.
Bu yüzden SQL Server’a yüksek gecikmeyle bağlanan uygulamaların yönetilen thread pool baskısını izlemesi öneriliyor. Gerekirse yönetilen thread pool boyutu artırılabilir ya da veritabanı işlemlerine eşzamanlılık sınırı konabilir. Microsoft, ilerideki çalışmalarda bu ağ çağrılarını düzelterek ek thread pool baskısını ortadan kaldırmayı planladığını belirtiyor.
Pool V2 nasıl etkinleştirilir?
Pool V2, Microsoft.Data.SqlClient 7.1.0 sürümünden itibaren kullanılabiliyor. Uygulama başlangıcında, herhangi bir veritabanı bağlantısı açılmadan önce bir kez etkinleştirmek yeterli:
AppContext.SetSwitch(
"Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2",
true);
Anahtarı uygulamanızın giriş noktasının en başına, veritabanına erişebilecek servisleri başlatmadan önce yerleştirin. ASP.NET Core uygulamalarında application builder oluşturulmadan önce konumlandırılmalı.
Gereken kod değişikliği bundan ibaret; mevcut connection string’leriniz ve veritabanı erişim kodunuz olduğu gibi kalıyor. Pool V2, EF Core ve Dapper dahil Microsoft.Data.SqlClient kullanan diğer kütüphanelerle de çalışıyor. Geri dönmek isterseniz anahtarı false yapıp uygulamayı yeniden başlatmanız yeterli.
Hangi senaryolarda değerlendirmeli?
Microsoft, Pool V2’yi temsili bir iş yüküyle denemeyi öneriyor, özellikle şu durumlarda:
- Uygulama açılışı,
- Sessiz bir dönemin ardından gelen trafik patlamaları,
- Veritabanı bağlantılarına yönelik yüksek eşzamanlı talep,
- SQL Server’a yüksek gecikmeli bağlantılar.
Pool V2’nin ileriki bir Microsoft.Data.SqlClient sürümünde varsayılan hale getirilmesi planlanıyor, dolayısıyla deneyimlerinizi dotnet/SqlClient GitHub Issues üzerinden paylaşmanız geri bildirim açısından değerli.
Kaynaklar ve İleri Okuma
- Try SqlClient’s new connection pool for faster parallel connections — Malcolm Daigle, Azure SQL Dev Corner
- System.Threading.Channels API dokümantasyonu
- dotnet/SqlClient GitHub deposu (benchmark kaynak kodu)
- Azure SQL Dev Corner blogu
- .NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak







Yorum gönder