Monafy’de bir fiyatın ekrana geç ulaşması, Kafka’nın yavaş olduğunu tek başına göstermiyor. Fiyat önce kaydediliyor, yayınlanmayı bekliyor, Kafka’ya gidiyor ve tüketici tarafından veritabanına uygulanıyor. Bu adımların herhangi biri toplam süreye bekleme ekleyebiliyor.
Akışı incelerken önce tek bir “gecikme” sayısını parçaladım. Sağlayıcının yayın gecikmesini, kendi servislerimizde geçen zamanı ve tarayıcıya ulaşma süresini ayrı ele almak gerekiyordu. Kullanıcının gördüğü veri gecikmesiyle bizim azaltabileceğimiz işleme süresinin sınırı böyle belirginleşti.
Ölçümün başlangıcını ve bitişini tanımlamak
Aynı fiyatın farklı adımlardaki zaman damgalarını eşleştirerek her bölümde geçen süreye baktım. Burada saat hassasiyeti önemli: yalnız saniye tutan bir kayıt, saniyeden kısa bir iyileştirmeyi güvenilir biçimde göstermez. Başlangıç ile bitişin aynı olayı tarif etmesi de gerekiyor.
Dağılımı yalnız ortalamayla okumadım. Medyan tipik beklemeyi, yüksek yüzdelikler ise daha geç işlenen olayları görünür kılıyor. Farklı adımların medyanlarını toplamak uçtan uca medyana eşit olmayacağı için, uçtan uca süre ayrıca ölçülmeli.
- KaydetFiyat ve yayınlanmayı bekleyen durum
- YayımlaKaydı Kafka’ya aktar
- UygulaTüketici veriyi ve konumu kaydeder
- GösterGüncelleme istemciye ulaşır
Yayıncının bekleme davranışını değiştirmek
İlk dikkat çeken yer, yayımlanacak kayıt bulunmadığında uyuyan süreçti. Kontrolden hemen sonra gelen bir fiyat, yeni iş hazır olsa bile bir sonraki kontrolü bekliyordu. Buradaki süre mesaj taşıma maliyetinden çok zamanlama kararıydı.
PostgreSQL NOTIFY, yayıncıyı yeni kayıt olduğunda uyandırmak için kullanıldı. Bildirim fiyatın kendisini taşımıyor; kalıcı veri ve Kafka hattı yerinde duruyor. Bildirim alınmasa da düzenli kontrol devam ettiği için yalnız uyanma sinyaline bağımlı bir akış oluşmuyor.
Transaction içindeki işin görünürlük maliyeti
Yayıncı daha erken uyandığında bile kaydedilen satır commit edilmemişse okuyamıyor. Kayıt sürecinin aynı transaction içinde yaptığı yardımcı bir tablo güncellemesi, fiyat hazır olduğu halde dışarıya görünmesini bekletiyordu.
Bu yardımcı işin fiyat grubuyla aynı atomik sınırda bulunması gerekmiyordu. Önce fiyat grubunu commit edip yardımcı tabloyu ayrı işlemde güncellemek, yayıncının asıl veriyi daha erken görmesini sağladı. Buradaki karar, sorguyu hızlandırmaktan önce transaction’ın hangi işleri birlikte tutması gerektiğini netleştirmekti.
Tüketicinin toplama süresini kullanım amacına göre seçmek
Tüketici tarafında da ilk mesaj geldikten sonra grubun dolmasını bekleyen süre vardı. Güncel fiyat akışında bu bekleme doğrudan ekrana yansırken, büyük tarihsel veri yüklerinde daha geniş gruplar yararlı olabiliyor. Aynı ayarı bütün tüketicilere uygulamak iki farklı ihtiyacı tek karara bağlıyordu.
Bu yüzden fiyat tüketicileri ile toplu veri tüketicilerinin bekleme davranışını ayrı değerlendirdik. Düşük trafik koşulunda da ölçüm yaptım; grup tek olaydan oluştuğunda işlem maliyetinden çok bekleme süresi belirleyici olabiliyor.
Hız ile yeniden işleme doğruluğunu birlikte değerlendirmek
Daha erken yayınlamak, kalıcı kayıt sırasını değiştirmek anlamına gelmemeli. Tüketici konumunu veriyle birlikte kaydetme kararını PostgreSQL ve Kafka vaka incelemesinde ele alıyorum. Gecikme için yaptığımız değişiklikler bu sınırın etrafında değerlendiriliyor.
Fiyatları daha sık göndermek de her zaman ücretsiz bir kazanç değil. Mesaj sayısı, veritabanı işi ve istemci güncellemeleri birlikte artabilir. Bir adımı azaltmadan önce beklemenin ürün için neyi sağladığını ve kaldırılmasının bütün hatta hangi yükü eklediğini ölçmek gerekiyor.