Bu sayfa, Proxus performans benchmarkının neyi ölçtüğünü, neyi kapsamadığını ve sonuçların boyutlandırma açısından nasıl yorumlanması gerektiğini açıklar.
Genel Bakış
Bu sayfadaki sonuçlar, simüle saha girdisi altında çalışan tek gateway pipeline throughput değerlerini gösterir.
Amaç, Proxus collection-to-storage zincirinin kontrollü benchmark koşullarında ne kadar trafik işleyebildiğini göstermektir. Bu sonuçlar; gerçek PLC, CNC, sensör, saha ağı veya fiziksel protokol davranışı benchmarkı değildir.
Bu dokümandaki doğrulanmış profillerde gözlenen throughput yaklaşık 0.55 milyar ile 29.8 milyar işlenmiş operasyon/gün arasında değişti.
Doğrulanan profillerin aritmetik ortalaması yaklaşık 8.9 milyar işlenmiş operasyon/gün oldu.
En yüksek gözlenen profil şu koşulları kullandı:
16 cihaz- cihaz başına
1.000 tag 50mssource polling- shared storage sink
- warmup sonrası
20sölçüm penceresi
Bu profil altında gözlenen sonuç yaklaşık 27.19 milyar işlenmiş operasyon/gün oldu. Aynı setteki en düşük doğrulanmış profil ise yaklaşık 0.55 milyar operasyon/gün seviyesindeydi.
Bu benchmark, Proxus pipeline throughput'unu simüle giriş altında ölçer. Donanım benchmarkı değildir ve koşulsuz bir SLA olarak yorumlanmamalıdır.
Benchmark Görüntüleri
Bu Benchmark Ne Ölçer
Benchmark, simüle saha girdisinden Proxus gateway pipeline'ına giren uçtan uca akışa odaklandı:
- gateway üzerinde simüle veri toplama
- platform içinde işleme ve yönlendirme
- verinin depolamaya teslim edilmesi
Bu yaklaşım, salt veritabanı insert testinden daha anlamlıdır; çünkü ürün içindeki ingestion, scheduling, processing, routing ve storage delivery maliyetini birlikte içerir.
Bu Benchmark Ne Ölçmez
Bu benchmark şunları ölçmez:
- gerçek cihaz okuma gecikmesi
- PLC, CNC, RTU veya sensör yanıt süreleri
- fiziksel ağ üzerindeki protokol davranışı
- kablolama, fieldbus yoğunluğu veya switch gecikmesi
- üreticiye özel cihaz performans sınırları
Donanım davranışını, ağ gecikmesini veya protokol round-trip süresini anlamak istiyorsanız, gerçek cihazlar ve gerçek ağ koşullarıyla ayrı bir workload doğrulaması yapılmalıdır.
Simülasyon Yöntemi
Bu koşularda saha girdisi fiziksel cihazlardan değil, platformun simulator yolundan üretildi.
Bu nedenle benchmark şu sorulara cevap verir:
- tek gateway'in ne kadar simüle cihaz/tag trafiği işleyebildiği
- polling sıklığı ve workload şekli değiştiğinde platformun nasıl davrandığı
- collection-to-storage pipeline'ının hangi throughput seviyelerini taşıyabildiği
Şu soruya cevap vermez:
- belirli bir PLC ailesinin, CNC denetleyicisinin veya sensör grubunun üretimde ne hızda okunabildiği
Test Ortamı
Raporlanan koşuların ortak ortamı şuydu:
- tek gateway
- simüle saha girdisi
- shared storage sink
- warmup sonrası
20sölçüm penceresi - Apple M4 Max test makinesi
14CPU core36 GBRAMmacOS 26.2
İki benchmark ailesi kullanıldı:
- Baseline profil: production’a daha yakın
1000mspolling - Yüksek frekans profili:
100ms,50msveya25msgibi daha agresif polling
Sonuç Nasıl Yorumlanmalı
Bu sonucu pipeline boyutlandırma referansı olarak kullanın; nihai dağıtım taahhüdü olarak değil.
En faydalı olduğu sorular:
- tek bir gateway'in simüle saha girdisi altında hangi büyüklükte yük taşıyabildiği
- ilk kurulum için tek gateway'in yeterli olup olmayacağı
- hangi noktada tek düğüm boyutlandırmasından yatay ölçeklemeye geçilmesi gerektiği
Bu sayı, her workload'ın aynı günlük hacme ulaşacağını iddia etmek için kullanılmamalıdır ve gerçek cihaz okuma performansının kanıtı gibi sunulmamalıdır.
Kamusal mesaj için aritmetik ortalama en dengeli özettir. Mühendislik kararı verirken tek bir başlık sayısı yerine profil tablosunun tamamı kullanılmalıdır.
Referans Ölçümler
Aşağıdaki ölçümler, simüle giriş kullanan izole smoke benchmark koşularından alınmıştır. Günlük hacim değeri, her koşuda gözlenen işlenmiş tag hızından türetilmiştir.
| Profil | Polling | Tags/s | Günlük operasyon | Tepe CPU | Tepe RSS |
|---|---|---|---|---|---|
64 cihaz x 100 tag | 1000ms | 6,395 | 552,528,000 | 4.7% | 140.0 MB |
64 cihaz x 100 tag | 500ms | 13,269 | 1,146,441,600 | 5.7% | 139.9 MB |
64 cihaz x 100 tag | 250ms | 25,554 | 2,207,865,600 | 20.5% | 147.4 MB |
64 cihaz x 100 tag | 100ms | 63,505 | 5,486,832,000 | 20.0% | 148.5 MB |
1000 cihaz x 100 tag | 1000ms | 99,846 | 8,626,694,400 | 14.7% | 148.8 MB |
16 cihaz x 1.000 tag | 1000ms | 14,795 | 1,278,288,000 | 18.0% | 148.8 MB |
16 cihaz x 1.000 tag | 500ms | 31,687 | 2,737,756,800 | 26.0% | 148.9 MB |
16 cihaz x 1.000 tag | 250ms | 63,904 | 5,521,305,600 | 21.7% | 147.9 MB |
16 cihaz x 1.000 tag | 100ms | 158,343 | 13,680,835,200 | 8.3% | 147.4 MB |
16 cihaz x 1.000 tag | 50ms | 314,655 | 27,186,192,000 | 20.1% | 148.0 MB |
16 cihaz x 1.000 tag | 25ms | 344,625 | 29,775,600,000 | 25.9% | 147.8 MB |
Buradaki CPU ve RSS değerleri, benchmark sürecinin kendi gözlenen tepe process değerleridir. Koşular arasında karşılaştırma yapmak için faydalıdır, ancak tüm host seviyesindeki kapasite profilini tek başına temsil etmez.
Throughput'u Dağıtımdan Dağıtıma Ne Değiştirir
Gözlenen throughput, workload şekline güçlü biçimde bağlıdır:
- Cihaz sayısı: cihaz sayısı arttıkça koordinasyon ve scheduling maliyeti artar
- Tag yoğunluğu: cihaz başına daha fazla tag, payload boyutunu ve depolama baskısını artırır
- Polling profili: daha sık polling daha yüksek yazma baskısı üretir
- Retention ve saklama politikası: yazma yoğun ve uzun saklama senaryoları farklı boyutlandırma ister
- Eşzamanlı analitik yükleri: panolar, sorgular ve export akışları ingestion ile aynı kaynakları paylaşır
Bu nedenle günlük toplam operasyon sayısı aynı olan iki dağıtım, özellikle gerçek cihazlar ve gerçek ağlar devreye girdiğinde farklı davranabilir.
Benchmark Sınırları
Bu benchmark tüm performans sorularını cevaplamaz.
Tek başına şu konuları tanımlamaz:
- karma read/write yükü altındaki sorgu performansı
- uzun tarihsel saklama pencerelerindeki retention maliyeti
- çoklu gateway toplama sınırları
- her protokol ve cihaz karmasının tam üst sınırı
- gerçek donanım okuma performansı
Bir dağıtım benchmark zarfına yaklaşıyorsa, beklenen cihaz sayısı, tag profili, polling sıklığı, ağ koşulları ve gerçek donanım ile workload’a özel doğrulama yapılmalıdır.
Kamusal mesajlarda kullanılan performans ifadesi, gerçek cihaz performansına değil, simüle giriş altındaki pipeline performansına bağlanmalıdır.