“Mengapa Latensi Solana ShredStream Saya Terus Meningkat?” Penyebab dan Solusinya

“Mengapa Latensi Solana ShredStream Saya Terus Meningkat?” Penyebab dan Solusinya

“Mengapa Latensi Solana ShredStream Saya Terus Meningkat?” Penyebab dan Solusinya
Di ERPC, kami sering menerima pertanyaan dari pelanggan yang menggunakan stream data real-time Solana dan melaporkan bahwa “latensi ShredStream meningkat secara bertahap lalu akhirnya berhenti”.
Dalam artikel ini, kami menjelaskan penyebab utama masalah tersebut secara jelas dan menawarkan solusi konkret untuk meningkatkan performa aplikasi Anda.

Mengapa Latensi ShredStream Terus Meningkat?

Saat ini, ShredStream mengirimkan hampir semua data real-time tanpa filter. Karena itu, jika kemampuan pemrosesan klien tidak memadai, data akan menumpuk dan latensi meningkat secara bertahap.
Penyebab utamanya adalah sebagai berikut:

1. Pemrosesan dengan Node.js atau Lingkungan Single-Thread

Pada awalnya, klien ShredStream dibuat menggunakan TypeScript dan protokol gRPC. Namun, karena filter belum diimplementasikan, lingkungan single-thread seperti Node.js cepat mencapai batas pemrosesan sehingga latensi terus meningkat.
Kami menemukan bahwa masalah tersebut tidak terjadi ketika klien Rust digunakan pada mesin yang sama. Hal ini mengonfirmasi keterbatasan pemrosesan single-thread.

Solusi: Multithreading dengan NAPI-RS

Sebagai tanggapan, kami mengembangkan solusi dengan teknologi NAPI-RS. Solusi ini memungkinkan pemrosesan multithread di Rust sambil mempertahankan kendali dari TypeScript. Solusi yang dikenal sebagai Solana Stream SDK ini bersifat open source dan tersedia untuk umum:
Jika Anda menggunakan Node.js atau TypeScript, kami sangat menyarankan penggunaan SDK ini. Untuk performa maksimal, pertimbangkan bahasa multithread native seperti Rust.

2. Performa Server Tidak Memadai, Khususnya Clock CPU

Aplikasi stream real-time yang menggunakan Solana ShredStream biasanya dapat berjalan dengan baik pada server 4 core dan RAM 16 GB. Namun, clock CPU sangat penting. Clock yang rendah dapat membuat latensi terus meningkat secara bertahap.
Server yang dirancang untuk memaksimalkan keuntungan sering menggunakan CPU generasi lama atau CPU dengan banyak core tetapi clock rendah. Sebagai contoh, CPU AMD EPYC generasi ke-4 dengan banyak core, seperti model 84 core, biasanya memiliki clock dasar sekitar 2,2 GHz dan sering tidak memanfaatkan turbo boost secara efektif. Karena persyaratan minimum yang direkomendasikan untuk validator Solana adalah 2,8 GHz, kami sangat menyarankan klien juga menggunakan CPU dengan clock sedikitnya sebesar itu.
Selain itu, penyedia VPS umumnya menggunakan “overcommitment”, yaitu praktik membagi satu server fisik menjadi beberapa server virtual. Dalam lingkungan yang mengalami overcommitment, perebutan sumber daya dengan pengguna lain sering terjadi pada waktu sibuk dan berdampak buruk pada performa.

Solusi: Gunakan VPS dengan CPU Generasi Terbaru Berfrekuensi Tinggi

ERPC menyediakan server VPS dengan CPU AMD EPYC generasi terbaru yang memiliki clock hingga 4,15 GHz. Server tersebut menawarkan performa yang mendekati solusi bare metal dan sangat sesuai bagi beban kerja Solana yang memerlukan stream data real-time.
Sebelumnya, solusi VPS berfrekuensi tinggi tidak tersedia sehingga pengguna yang membutuhkan performa real-time terpaksa memilih server bare metal. Produk VPS ERPC mengatasi keterbatasan tersebut.

Kami Merekomendasikan EPYC VPS Berperforma Tinggi

VPS ERPC
Solusi VPS ERPC dioptimalkan untuk streaming data real-time Solana dan mendapat tanggapan sangat positif dari banyak trader berfrekuensi tinggi serta proyek.
Solusi ini ideal bagi pelanggan yang membutuhkan performa tinggi tanpa memerlukan seluruh sumber daya server bare metal.
Kami mengundang Anda untuk mencoba solusi VPS kami.
Untuk uji coba gratis atau konsultasi terperinci, kunjungi Discord resmi Validators DAO:
ERPC akan terus melakukan riset dan pengembangan untuk memenuhi kebutuhan Anda yang terus berkembang serta mendukung peningkatan performa.
Terima kasih atas dukungan Anda.