PostgreSQL protokolünü QUIC ile çalıştırmak istemci darboğazını çözüyor
Öne çıkanlar
- QUIC tabanlı mimari yoğun yük altında 246 milisaniye gecikmeyle saniyede 9 bin 718 sorgu işledi.
- Aynı yük altındaki geleneksel TCP havuzunda 40 binden fazla sorgu birikti ve gecikme 7 bin milisaniyenin üzerine çıktı.
- Protokol değişikliği için PostgreSQL tel protokolünde değişiklik yapılmadı, PgCat havuzlayıcısı uyarlandı.
Geliştiriciler, dağıtık sistemlerde PostgreSQL bağlantı havuzlarının istemci tarafında yarattığı ağ darboğazını aşmak için TCP yerine UDP tabanlı QUIC protokolünü test etti. PostgreSQL kablo protokolü bağlantı başına eşzamanlı tek bir sorguya izin verdiği için coğrafi olarak uzak istemcilerde soket tükenmesi ve bellek yığılması yaşanıyor. Yapılan deneysel çalışmada PgCat havuzlayıcısı QUIC bağlantılarını kabul edecek şekilde yeniden düzenlendi ve sonuçlar paylaşıldı.
Yoğun yük altında gerçekleştirilen testlerde QUIC mimarisi saniyede 9 bin 718 sorgu işlerken ortalama 246 milisaniye gecikme sundu. Aynı iş yükünü geleneksel TCP havuzuyla çalıştıran sistemde ise 40 binden fazla sorgu birikti ve ortalama gecikme süresi 7 bin 88 milisaniyeye kadar çıktı. İstemci bellek kullanımı TCP tarafında bekleyen sorgular nedeniyle 9 megabayttan 474 megabayta yükseldi.
QUIC protokolü tek bir bağlantı üzerinde çekirdek soketi açmadan bağımsız çift yönlü akışlar oluşturuyor ve satır başı engellemesini önlüyor. Bu mimari özellikle uç bilişim noktaları ile merkezi veritabanları arasındaki yüksek ağ gecikmesine sahip yapılarda tekil sorgu performansını doğrudan artırıyor. Ancak çok adımlı etkileşimli işlemlerde arka uç veritabanı bağlantısı kilitlendiği için QUIC bu senaryolardaki beklemeleri çözmüyor.
Bu özet yapay zekâ ile hazırlanmıştır; ayrıntılar ve doğrulama için orijinal kaynağa başvurun.