Solana VPS vs Bare Metal: pengujian CPU, UDP, jaringan | ERPC

Mengapa server sama pentingnya dengan stream Solana

Stream Solana cepat tidak otomatis membuat data tiba tepat waktu untuk aplikasi. CPU yang terlihat lengang dan port 1 Gbps bukan bukti bahwa penerimaan data baik. Periksa seluruh perjalanan dari sumber data ke aplikasi. Panduan ini menggunakan observasi anonim, tes independen, dan benchmark terbuka tanpa menyalahkan penyedia yang akar masalahnya belum terbukti.

Solana cepat dan mengalirkan banyak paket

Shreds dan Yellowstone Geyser gRPC dapat mengirim data terus-menerus dengan lonjakan sesaat. Bandwidth, paket per detik (PPS), RTT, jitter, kehilangan paket, dan waktu pemrosesan adalah metrik berbeda. Contoh 4 MB/s selama 30 hari menghasilkan 10,4 TB, tetapi rata-ratanya hanya 32 Mbps. Angka itu bukan bukti bahwa 1 Gbps kurang. Periksa batas UDP, lonjakan, uplink bersama, dan kemampuan penerima.

Stream aktif tetapi data tidak lengkap

Dalam satu investigasi anonim, pengirim mencatat sekitar 3.400–3.900 paket UDP/detik, sedangkan penerima melaporkan sekitar 13 paket/detik pada waktu berbeda. Shreds yang diterima valid tetapi tidak cukup untuk rekonstruksi. gRPC berfungsi di server yang sama. Karena jendela waktu dan titik pengukuran tidak cocok, ini bukan persentase kehilangan paket atau penyebab yang sudah pasti. Beberapa ribu PPS tidak otomatis berat bagi server umum.

Cari lokasi observasi sebelum mengganti mesin

Kebijakan jaringan, pelindung DDoS, atau host virtualisasi dapat membatasi UDP sebelum tiba di VM. Setelah NIC, kernel, buffer socket, dan aplikasi juga bisa membuang paket. Mulailah dengan tcpdump lalu cek penghitung NIC, kesalahan UDP, dan antrean. XDP bisa membuang paket sebelum tcpdump melihatnya. Samakan waktu, tujuan, dan port ketika membandingkan pengirim dengan penerima.

Satu kota bukan berarti rute pendek

Dua server di Frankfurt mungkin berada pada fasilitas dan jaringan berbeda serta melewati transit eksternal. Dari satu host, dua endpoint Amsterdam yang saling berjarak sekitar 0,1 ms menghasilkan RTT sekitar 11 ms dan 23 ms. Pada periode lain jaringan upstream mengalami kehilangan 5–8% dan tambahan delay sekitar 5 ms. Ini khusus untuk rute tersebut, bukan gambaran semua penyedia.

Jalankan aplikasi lebih dekat ke sumber data

Biasanya penyedia RPC menjual data dan penyedia hosting menjual komputasi secara terpisah. ERPC merancang Shreds, Geyser gRPC, RPC, VPS, dan Bare Metal bersama. Di lokasi yang didukung, sumber data dan host aplikasi bisa berkomunikasi lewat jaringan lokal antar-rak berdekatan tanpa putaran eksternal yang tidak perlu. Zero-Distance Communication bukan klaim nol latensi literal; ukur rute yang dipakai.

Bandingkan data yang benar-benar diterima

Untuk langganan Geyser gRPC sebanding ke endpoint Amsterdam yang sama, hosting eksternal mencatat 3,7–4,2 MiB/s dan lag bertambah. Tes independen pada ERPC VPS Frankfurt yang dibatasi satu inti menghasilkan rata-rata 9,396 MiB/s dan sekitar 1.910 transaksi/s selama 60 detik tanpa akumulasi lag. Ada retransmisi TCP di rute yang bermasalah. Host dan implementasi klien berbeda, jadi bukan A/B terkontrol. Tes HTTP/2 lain mencatat 2,7 MB/s pada jendela 16 KiB dan hingga 7,1 MB/s pada jendela yang lebih besar.

Nama CPU tidak menampilkan semua batas

VM dengan generasi CPU dan vCPU sama bisa memiliki aturan boost, daya, pendinginan, dan scheduling berbeda. AMD Core Performance Boost atau Intel Turbo Boost dapat dimatikan oleh BIOS atau host. Bahkan jika hidup, clock maksimum tidak dijamin saat beban berkelanjutan. VM tamu mungkin tidak dapat melihat kebijakan host. Ukur performa nyata yang berkelanjutan.

Empat vCPU, perbedaan benchmark 1,93×

Benchmark publik ERPC atas AMD Turin empat vCPU dengan Ubuntu 24.04 di Amsterdam mencatat 7.850 berbanding 4.062 events/s untuk sysbench CPU, sekitar 1,93× pada tes itu. Perbandingan yang sama melaporkan sekitar 3,2× bandwidth memori dan 16,6× IOPS baca acak 4K. Angka tersebut bukan jaminan bagi semua aplikasi dan tidak membuktikan boost sebagai satu-satunya penyebab.

Ekonomi data center memengaruhi kinerja

Listrik, pendinginan, rak, switch, koneksi, dan operasi membutuhkan biaya. Berbagi kapasitas masuk akal untuk aplikasi biasa. Namun beban Solana yang berat dapat memakai CPU, PPS, dan uplink secara terus-menerus. Jaringan berbagi, pembatasan per koneksi, DDoS protection, dan hemat energi dapat cocok untuk penggunaan lain. Ukurlah kecocokan kebijakannya tanpa menyalahkan penyedia.

Hitung pula biaya transfer cloud

Stream berkelanjutan mengumpulkan terabyte dari waktu ke waktu. Ingress Internet sering gratis di beberapa cloud, tetapi egress dan komunikasi antar-zona/layanan bisa berbayar. Produk ERPC yang memenuhi syarat memisahkan lalu lintas internal platform dari kuota transfer eksternal sesuai kontrak terbaru. Hitung total biaya jalur data, bukan harga VM saja.

Pilih server sesuai beban kerja

EPYC VPS mungkin cukup untuk RPC ringan; analitik gRPC terus-menerus butuh CPU dan memori yang cukup. Shreds UDP dan aplikasi latensi rendah harus mengukur kebijakan UDP, PPS, lonjakan, kedekatan rak, dan waktu deteksi. Bare Metal memberi sumber daya fisik eksklusif tetapi tidak selalu lebih cepat. Beberapa VPS juga bisa efektif. Bandingkan filter, software, waktu, Shreds valid, rekonstruksi, lag, retransmisi, dan p95/p99.

Ukur sebelum kontrak panjang

Di Linux, tcpdump, nstat, ip -s link, ethtool -S, ss -tin, dan lscpu dapat digunakan untuk pemeriksaan awal read-only. Ganti IP dan antarmuka contoh, ukur selisih penghitung, dan perhatikan drop pada capture. lscpu saja tidak menunjukkan kebijakan boost hypervisor. ERPC menawarkan tagihan per jam untuk VPS dan Bare Metal yang memenuhi syarat sesuai stok. Pilih server yang membuat data siap dipakai tepat waktu.

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