Solana VPS ve Bare Metal: CPU, UDP, ağ testleri

Solana akışı kadar onu çalıştıran sunucu da önemli

Hızlı Solana akışı, verinin uygulamaya zamanında ulaştığı anlamına gelmez. Düşük CPU yükü ve reklamı yapılan 1 Gbps port eksik Shreds veya büyüyen gRPC gecikmesini açıklamaz. Kaynaktan uygulamaya bütün yol ölçülmelidir. Bu yazıda anonimleştirilmiş incelemeler, bağımsız testler ve açık benchmarklar kullanılır; kanıtlanmamış bir sorunun sorumluluğu tek bir sağlayıcıya yüklenmez.

Yüksek hız sürekli ve ani paket yükü demek

Shreds ve Yellowstone Geyser gRPC sürekli veri taşır, zaman zaman kısa patlamalar oluşturur. Bant genişliği, saniyede paket (PPS), RTT, jitter, kayıp ve uygulama işlem süresi farklı ölçümlerdir. Varsayımsal 4 MB/s, 30 günde yaklaşık 10,4 TB eder, ancak ortalama yalnızca 32 Mbps'dir. Bu, 1 Gbps portun yetmediğini kanıtlamaz. UDP sınırlarını, paylaşılan uplinkleri ve alıcıyı da test edin.

Akış açık olsa da parçalar eksik kalabilir

Anonim bir incelemede göndericide yaklaşık 3.400–3.900 UDP paket/s ölçüldü; farklı bir zamanda alıcı yaklaşık 13 paket/s bildirdi. Gelen Shreds geçerliydi ama yeniden kurmaya yetmiyordu. Aynı sunucuda gRPC çalışıyordu. Bu gözlemler aynı zaman ve noktaya ait değildir; kesin kayıp oranı veya kök neden çıkarılamaz. Birkaç bin PPS tek başına sıradan bir sunucu için aşırı yük değildir.

Önce paketlerin nerede gözlendiğini belirleyin

Ağ politikası, DDoS koruması veya sanallaştırma ana makinesi UDP'yi VM'den önce sınırlayabilir. NIC'den sonra kernel, soket tamponu ve uygulama paket düşürebilir. Önce tcpdump ile giriş arayüzünü inceleyin; ardından NIC sayaçları, UDP hataları ve kuyrukları kontrol edin. XDP, tcpdump görmeden önce düşürebilir. İki uçta aynı zaman aralığını, portu ve hedefi karşılaştırın.

Aynı şehir kısa ağ yolu demek değil

Frankfurt'taki iki sunucu ayrı tesislerde olup dış transit üzerinden konuşabilir. Aynı uzak makineden Amsterdam'daki birbirine yaklaşık 0,1 ms yakın iki endpoint için yaklaşık 11 ms ve 23 ms RTT ölçüldü. Başka bir aralıkta upstream yolunda %5–8 kayıp ve yaklaşık 5 ms ek gecikme raporlandı. Bunlar yalnızca ilgili güzergâhın gözlemleridir, tüm sağlayıcıların değil.

İşlemeyi veri kaynağına yaklaştırın

RPC sağlayıcısı veriyi, hosting şirketi sunucuyu ayrı sunar. ERPC Shreds, Geyser gRPC, RPC, VPS ve Bare Metal'i birlikte tasarlar. Desteklenen noktalarda yakın raflar ve yerel ağ yolu gereksiz dış dolaşımı azaltabilir. Zero-Distance Communication kelimenin gerçek anlamıyla sıfır mesafe ya da garantili gecikme demek değildir. Gerçek yolu ölçün.

Uygulamaya gerçekten ulaşan veriyi ölçün

Aynı Amsterdam endpointine benzer Geyser gRPC aboneliğinde bir dış ortam 3,7–4,2 MiB/s ile artan gecikme gördü. Bir çekirdeğe sınırlandırılmış ERPC Frankfurt VPS bağımsız testinde 60 saniye boyunca ortalama 9,396 MiB/s ve yaklaşık 1.910 işlem/s alındı, biriken gecikme yoktu. Sorunlu rotada TCP retransmission gözlendi. Farklı host ve istemciler kullanıldığından kontrollü A/B testi değildir. Ayrı HTTP/2 deneyinde 16 KiB pencere 2,7 MB/s, daha büyük pencere 7,1 MB/s'ye kadar verdi.

CPU adı gerçek sınırları göstermez

Aynı nesil işlemci ve vCPU sayısında boost, güç, soğutma ve scheduling politikaları farklı olabilir. AMD Core Performance Boost ve Intel Turbo Boost BIOS ya da host düzeyinde kapatılabilir. Açık olsa da en yüksek frekansın sürekli korunacağı garanti değildir. Misafir VM, host politikasını görmeyebilir. Gerçek iş yükünde kalıcı performansı ölçün.

Dört vCPU, ölçümde 1,93 kat fark

ERPC'nin Amsterdam'daki AMD Turin dört vCPU ve Ubuntu 24.04 karşılaştırmasında sysbench CPU 7.850 karşısında 4.062 events/s ölçtü: bu teste özgü yaklaşık 1,93×. Aynı yayında bellek bant genişliğinde yaklaşık 3,2×, 4K rastgele okuma IOPS'ta yaklaşık 16,6× belirtiliyor. Her uygulama için garanti değildir ve farkın yalnızca boosttan kaynaklandığını kanıtlamaz.

Veri merkezi ekonomisi teknik kararları etkiler

Elektrik, soğutma, raf, switch, ağ ve bakım maliyetlidir. Paylaşılan kaynaklar ve enerji tasarrufu sıradan uygulamalar için mantıklıdır. Yüksek trafikli Solana akışları CPU, PPS ve uplink üzerinde sürekli yük oluşturabilir. Paylaşılan bant genişliği, akış sınırları ve DDoS koruması başka müşteriler için uygundur. Şirketi suçlamak yerine iş yükünüze uygunluğu test edin.

Bulut trafik ücretlerini de hesaba katın

Sürekli akışlar zamanla terabaytlar oluşturur. Bazı bulutlarda internetten gelen veri ücretsiz, giden veri veya bölgeler/hizmetler arası trafik ücretli olabilir. Uygun ERPC ürünlerinde platform içi trafik ile dış veri kotası ayrı ele alınır; güncel planı kontrol edin. Sadece VM fiyatını değil, veri yolunun toplam maliyetini ölçün.

VPS veya Bare Metal'i işe göre seçin

Hafif RPC için EPYC VPS yeterli olabilir. Sürekli gRPC analizinde CPU ve bellek payı gerekir. Düşük gecikmeli UDP Shreds ve trading uygulamalarında UDP politikası, PPS, ani yük, yakın yerleşim ve algılama süresini ölçün. Bare Metal özel fiziksel kaynak sunar ama her zaman daha hızlı değildir. İşi birkaç VPS'e bölmek de faydalı olabilir. Aynı yazılım, filtre ve zamanlarda Shreds, reconstruction, lag, yeniden iletim ve p95/p99 karşılaştırın.

Uzun sözleşmeden önce ölçün

Linux'ta tcpdump, nstat, ip -s link, ethtool -S, ss -tin ve lscpu ile ayar değiştirmeden ilk kontrolü yapabilirsiniz. Örnek IP'yi ve arayüzü değiştirin; sayaçların zaman farkını ölçün. lscpu tek başına hipervizörün boost politikasını göstermez. ERPC uygun VPS ve Bare Metal seçeneklerinde stok durumuna göre saatlik ödeme sunar. Veriyi zamanında kullanılabilir kılan sunucuyu seçin.

bash

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu