Vapor'un maximumActiveConnections Ayarı Worker Başına Değil, Event Loop Başınadır

Yanıltıcı Yapılandırma

Vapor’da bağlantı havuzlarını yapılandırırken – ister Redis, PostgreSQL veya diğer veritabanları için olsun – maximumActiveConnections adlı bir parametreyle karşılaşıyorsun. Doğal varsayım, bunun uygulamanın toplam maksimum bağlantısını ayarladığı. Ayarlamıyor. NIO EventLoop başına maksimumu ayarlıyor.

Bu ayrım production’da büyük önem taşıyor.

Beni Şaşırtan Hesap

Tipik bir sunucuda, Swift NIO her CPU çekirdeği için bir EventLoop oluşturuyor. Yani gerçek maksimum bağlantı sayısı:

gerçek max = maximumActiveConnections * CPU çekirdekleri * dyno/instance sayısı

maximumActiveConnections‘ı 8 olarak yapılandırmıştım, Redis bağlantılarımı iki dyno’da makul bir 16 ile sınırladığımı düşünüyordum. Gerçek sayı:

8 (event loop başına) * 8 (çekirdek) * 2 (dyno) = 128 potansiyel bağlantı

Bu, hedeflenenden bir büyüklük sırası daha fazla ve trafik zirveleri sırasında Redis sağlayıcımın bağlantı limitini aşıyordu.

Belirtiler

Başarısızlık modu özellikle sinsi: sadece yük altında ortaya çıkan aralıklı 500 hataları. Normal trafik sırasında gerçek bağlantı limitine asla ulaşmıyorsun, bu yüzden her şey sorunsuz çalışıyor. Zirveler sırasında, bağlantılar tüm event loop’larda aynı anda birikiyor ve sağlayıcının limitini aşıyor. Hatalar rastgele görünüyor ve geliştirme makinelerinde genellikle daha az çekirdek olduğundan yerel olarak tekrarlamak zor.

Doğru Değeri Nasıl Hesaplarsın

Sağlayıcının bağlantı limitini tüm instance’lardaki toplam event loop sayısına böl:

// Provider limit: 40 connections
// 2 dynos * 8 cores = 16 event loops total
// 40 / 16 = 2.5, round down to 2

app.redis.configuration = .init(
   pool: .init(maximumActiveConnections: 2)
)

Bu muhafazakar ayar, TranslateKit’teki aylardır beni şaşırtan uzun süredir devam eden nadir 500 hatalarını nihayet düzeltti. Her zaman bulut sağlayıcının bağlantı limitlerini kontrol et ve deploy etmeden önce çarpma işlemini yap.