rekuiper 0.500 hot path'i RAM'e taşıyor ve tek çekirdek limitlerini 200k msg/s'ye kadar kesin olarak belirliyor

Ne oldu

Edge ağ geçitleri ve IoT hub'ları için geliştirilen, LF Edge eKuiper'ın Rust ile yeniden yazılmış hali olan rekuiper, mesajları işlerken dosya sistemine hiç dokunmayan bir motorla 0.500-beta sürümünü yayınladı. ankurpaan'ın dev.to'daki yazısına göre, eş zamanlı yürütülen benchmark kampanyası, beş MQTT iş yükünün kesin tek çekirdek throughput limitini buldu — bazıları saniyede 200.000 mesaja kadar — ve sonuçları 1.000 msg/s artışlarla daraltan bir arama kullanıldı.

Gönderi bunu, önceki testlerin bıraktığı bir boşluğu kapatma olarak çerçeveliyor: rekuiper daha önce sabitlenmiş tek bir çekirdekte 100.000 msg/s'yi tutturmuş ama kendisine 200.000 sunulduğunda paket kaybediyordu. Bu iki nokta arasındaki her şey bilinmeyen bölgeydi ve üstelik başarısız olan her iş yükünde CPU bile doygun hale gelmemişti.

Limiti stream matematiği değil, disk I/O belirliyordu

Geliştiriciler motoru burst yükü altında profilediklerinde, darboğazın ne parsing ne de pencere aritmetiği olduğunu gördüler. Takılmalar metadata erişiminden kaynaklanıyordu: stream ve rule tanımları için SQLite tablolarının kontrol edilmesi, kimlik doğrulama anahtarlarının çözümlenmesi, yapılandırma dosyalarının okunması ve rule durumu değişikliklerinin kalıcı hale getirilmesi. Bir geliştirme makinesinin NVMe diskte bu tür aramalar mikro saniyeler tutuyor. eMMC veya microSD depolamaya sahip endüstriyel bir ağ geçidinde ise flash yazma batch'leri Tokio runtime thread'ini durduran I/O beklemleri yaratıyor.

Backpressure bunu hızla büyütüyor. Gönderi, 150k msg/s'de 10 milisaniyelik bir duraklamanın kabaca 1.500 mesajlık bir birikim ürettiğini, QoS 0 altında Mosquitto broker'ın bu paketleri tamamen düşürdüğünü belirtiyor. Tek çekirdekte 100k msg/s'yi aşmak için hot path'in diske hiç dokunmaması gerekiyordu.

v0.500'de ne değişti

Bu sürüm metadata okumalarını metadata kalıcılığından ayırıyor. Yeni MemoryCatalog, tüm stream, tablo ve aktif rule'ları açılışta bir kez SQLite'tan yüklüyor ve aramaları RwLock korumalı in-memory hash map'ler üzerinden sunuyor — çalışma sırasında sistem çağrısı ve disk I/O yok. Rule değişiklikleri önce belleği güncelliyor ve arka planda asenkron olarak SQLite'a işleniyor.

Catalog'un ötesinde ekip, JWT doğrulamasında kullanılan RSA public key'lerini önbelleğe aldı böylece ingest artık istek başına key dosyalarını okumuyor, yapılandırma ve şema verilerini ilk erişimde RAM'de önbelleğe aldı, SQL ve veritabanı sink'leri için paylaşımlı connection pool'lar ekledi ve ilişkisel sink'leri (PostgreSQL ve SQLite) kayıt başına bir sorgu yerine parametreli çok satırlı INSERT ifadelerine geçirdi. Dahili actor kuyruk derinlikleri 1.024'ten 32.768 kayda çıkarıldı; bu da motora, backpressure'u MQTT ağ döngüsüne yansıtmadan OS zamanlama titremesini emme payı verdi.

Tavanlar nasıl ölçüldü

Ekip yuvarlak sayıları test etmek yerine hiyerarşik bir merdiven koştu: tavanı belirlemek için kaba 10.000 msg/s adımları, ardından 2.500 msg/s adımları ve kırılma noktasını tam olarak bulmak için 1.000 msg/s adımları.

Test düzeneği önceki benchmark'larla aynı. 12 çekirdekli bir x86-64 ana makine WSL2 üzerinde Docker (cgroup v2) çalıştırıyor; motor container'ı tek bir CPU çekirdeğine sabitlenmiş, 1 GiB RAM ve eşit swap ile sınırlandırılmış ve tek bir Tokio worker thread'ine ayarlanmış. Mosquitto, ayrı çekirdeklerde izole bir container'da çalışıyor ve katı bir 4.096 mesaj / 1 MiB giden kuyruğuna sahip; böylece herhangi bir gecikme anında düşen QoS 0 paketlerine dönüşüyor. Bağımsız bir Rust load generator (mqttgen) sekiz bağlantı üzerinden MQTT 3.1.1 trafiği gönderiyor ve mesaj bazında sink doğrulaması sayıları, benzersiz ID'leri ve cihaz başına agregasyonları kontrol ediyor.

Sonuçlar

İş yükü	Tavan	İlk hata	Sınırlayıcı faktör	RAM
Telemetri filtresi (1.000 cihaz)	150.000 msg/s	151.000 msg/s	CPU %99,4'te, broker %20,5 düşürüyor	17,4 MB
Cihaz başına 10s pencereleri (1.000 cihaz)	200.000 msg/s	210.000 msg/s	Generator programdan saptı; motor 240k'ya kadar kayıpsız	6,7 MB
ESPHome topic'leri (10.000 topic)	150.000 msg/s	151.000 msg/s	CPU %99,3'te, broker %5,0 düşürüyor	16,6 MB
Araç pencereleri (10.000 VIN topic)	200.000 msg/s	210.000 msg/s	Generator programdan saptı; motor 220k'ya kadar kayıpsız	18,1 MB
EV şarj istasyonu oturumları	126.000 msg/s	127.000 msg/s	5 saniyelik stabilite limitine karşı 16 saniyelik oturum boşaltma gecikmesi	6,0 MB

İki iş yükü, motorun değil load generator'ın kendi zamanlama limitlerine takıldı. Cihaz başına pencereleme senaryosunda motor 240.000 msg/s'ye kadar her şeyi kayıpsız işledi ve pipeline 250.000'de çöktü; geliştiriciler 200.000'i sertifikalı plan-li tavan olarak tanımlıyor. Pencereleme ayrıca belleği küçük tuttu — 6,7 MB — çünkü count, average ve max gibi agregasyonlar ham satırları tamponlamak yerine yerinde güncelleniyor.

Neden önemli

Edge ağ geçitleri ve Raspberry Pi sınıfı donanımlar yavaş flash ve az çekirdekle yaşıyor ve bu yazı, böyle makinelerde stream işlemenin fiziksel tavanını parsing'in veya pencere matematiğinin değil metadata I/O'nun belirlediğini savunuyor. Catalog'ları ve key materyalini RAM'e taşımak, kalıcılığı asenkron write-back ile korumak ise tek çekirdekte kabaca 100k ile 150k–200k msg/s arasındaki farkı yarattı ve bunu, kısıtlı cihazlara sığacak kadar küçük bellek ayak izleriyle yaptı. Metodoloji de öne çıkıyor: sıkı şekilde sınırlandırılmış bir broker ve mesaj bazında doğrulama, kapasite planlayıcılarının gerçekten güvenebileceği tavan sayıları üretiyor. Her zamanki uyarılar geçerli — bunlar tek bir özel düzendeki beta yazılımın kendi raporladığı benchmark'ları — ama hot path'leri flash'tan uzak tutma konusundaki tasarım dersi bu projenin çok ötesine taşınıyor.