“Data Solana Lambat atau Tidak Lengkap?” Apa yang Perlu Diperiksa pada Infrastruktur Penerima
Anda berlangganan aliran Shreds Solana berkecepatan tinggi, tetapi hanya segelintir paket yang masuk. Shreds yang diterima dapat diurai dengan benar, tetapi terlalu banyak fragmen yang hilang sehingga transaksi tidak dapat diekstrak. gRPC berjalan di server yang sama, sehingga Anda tidak yakin harus memeriksa apa selanjutnya.
Selain memeriksa sisi pengirim, periksa juga server aplikasi Anda dan pusat data tempat server tersebut berada. Sekalipun ERPC meneruskan Shreds dengan cepat, pembatasan UDP di sepanjang jalur atau hambatan pemrosesan pada server penerima dapat menghalangi aplikasi Anda memanfaatkan kecepatan tersebut.
Memilih aliran Shreds berarti mempertimbangkan seluruh jalur: bagaimana paket tiba dan bagaimana paket tersebut menjadi data yang dapat digunakan. Kualitas jaringan, jarak, dan kebijakan operasional pusat data juga merupakan kondisi yang sama-sama memengaruhi kinerja Geyser Yellowstone gRPC, lalu lintas RPC dan API biasa, serta pengiriman transaksi.
Catatan sisi pengirim dan data yang dapat digunakan di sisi penerima adalah fakta yang berbeda
Dalam salah satu permintaan dukungan ERPC baru-baru ini, pengukuran singkat di sisi pengirim mencatat sekitar 3.400–3.900 paket/detik. Sisi penerima melaporkan sekitar 13 paket/detik dan tidak ada rekonstruksi slot yang selesai.
Angka-angka ini berasal dari periode pengukuran yang berbeda, dan metode pengukurannya belum dipastikan dapat dibandingkan. Karena itu, angka-angka tersebut tidak dapat digunakan untuk menentukan tingkat keberhasilan pengiriman maupun tingkat kehilangan paket. Catatan sisi pengirim saja tidak membuktikan bahwa paket telah tiba, dan penyebab akhirnya belum ditentukan saat artikel ini ditulis.
Beberapa ribu PPS juga tidak dengan sendirinya menunjukkan beban yang luar biasa tinggi untuk server serbaguna. Hal yang perlu ditelusuri adalah apa yang terjadi pada jalur sebenarnya, batasan apa yang berlaku, bagaimana lalu lintas terkonsentrasi dalam interval pendek, bagaimana penerimaan ditangani, dan apa yang diukur oleh setiap penghitung.
Sama-sama di Frankfurt, jalur jaringan bisa berbeda
Sumber aliran data dan server aplikasi Anda bisa sama-sama berada di Frankfurt, tetapi tetap menempati pusat data yang terpisah. Dalam konfigurasi seperti ini, lalu lintas dapat keluar dari satu fasilitas, melintasi jaringan eksternal, lalu masuk ke fasilitas lainnya. Label wilayah yang sama tidak berarti fasilitas, operator jaringan, atau kumpulan perangkat perantaranya juga sama.
Jika aliran data atau layanan RPC ERPC serta host ERPC VPS atau Bare Metal ditempatkan di lokasi yang sama, server layanan dan server aplikasi berada di rak yang berdekatan, dan komunikasi di antaranya tetap berada di jaringan internal. Inilah gagasan di balik Komunikasi Jarak Nol ERPC: merancang penempatan fisik dan jalur menuju aplikasi penerima secara bersamaan, melampaui sekadar memilih kota yang sama.
Menghindari jalur memutar melalui jaringan eksternal antara layanan ERPC dan server aplikasi memperpendek jalur dan mengurangi paparan segmen tersebut terhadap kemacetan serta perubahan rute di jaringan eksternal. Jalur pendek, ditambah sumber daya yang diperlukan untuk penerimaan dan pemrosesan, menjadi dasar untuk memanfaatkan aliran data yang cepat. Verifikasi hasilnya baik pada tahap kedatangan paket maupun pemrosesan aplikasi.
Kondisi jaringan memengaruhi setiap jenis komunikasi
Fragmen yang hilang membuat masalah terlihat jelas pada Shreds, tetapi kualitas infrastruktur yang sama juga memengaruhi penerimaan data, permintaan API, dan pengiriman transaksi secara lebih luas. Protokol menentukan gejala yang terlihat oleh aplikasi dan titik-titik yang perlu diukur.
| Komunikasi | Di mana dampak jaringan muncul | Hal yang diperiksa dalam aplikasi |
|---|---|---|
| Shreds / UDP | Kehilangan paket dan keterlambatan, serta kedatangan fragmen yang diperlukan untuk rekonstruksi | Shreds yang valid dan waktu hingga data dapat direkonstruksi |
| Geyser Yellowstone gRPC | Waktu tunggu transmisi ulang TCP, penumpukan data pada aliran, dan keterlambatan | Waktu hingga pembaruan yang sama diterima dan diproses |
| RPC, API, dan lalu lintas antarlayanan | Perjalanan pulang-pergi permintaan dan respons, serta waktu tunggu saat terjadi kemacetan | Waktu respons dan variasinya |
| Pengiriman transaksi | Jalur permintaan menuju node penerima | Waktu dari permintaan pengiriman hingga respons node |
Penempatan yang berdekatan dan kebijakan operasional yang sesuai mendukung seluruh lalu lintas ini. Ukur waktu respons node penerima secara terpisah dari waktu hingga transaksi dimasukkan ke blok dan difinalisasi di blockchain.
Gbps tidak menjelaskan seluruh kondisi PPS dan lonjakan lalu lintas
Bandwidth menggambarkan jumlah data yang dapat ditransmisikan dalam suatu rentang waktu. PPS menggambarkan jumlah paket yang diproses setiap detik. Sebuah koneksi dapat memiliki sisa bandwidth, tetapi sudah mencapai batas laju paket atau terkena pembatasan yang diterapkan pada UDP. Dokumentasi penyedia cloud sendiri memperlakukan kuota bandwidth dan PPS sebagai batasan yang terpisah.[1]
Shreds tidak selalu datang dengan laju yang merata. Lonjakan dapat menimbulkan tekanan pada antrean yang tidak terlihat dalam nilai rata-rata. Jika paket menumpuk lebih cepat daripada kemampuan perangkat jaringan atau penerima memprosesnya, paket yang melampaui kapasitas antrean dapat dibuang.[2]
Tanyakan kepada penyedia hosting tentang penerimaan UDP berkelanjutan, lonjakan singkat, batas PPS, dan aturan yang diterapkan oleh perlindungan DDoS. Tujuannya adalah menetapkan kondisi yang mengizinkan lalu lintas yang diperlukan masuk dengan aman, bukan menonaktifkan perlindungan secara sembarangan.
gRPC yang berjalan tidak membuktikan penerimaan UDP berjalan dengan benar
gRPC berbasis TCP dan Shreds mentah melalui UDP menggunakan mekanisme transport yang berbeda. TCP menyediakan transmisi ulang dan pengurutan, sementara komunikasi streaming gRPC memiliki kontrol aliran yang memperhitungkan kapasitas penerima. UDP sendiri tidak mengirim ulang paket yang hilang atau membuat pengirim menunggu sampai aplikasi penerima mengejar ketertinggalan pemrosesan.[3]
Karena itu, gRPC yang berfungsi pada sebuah server tidak membuktikan bahwa jalur UDP atau penerimanya bekerja dengan benar. Filter khusus protokol, port, jalur pengiriman, dan implementasi penerima perlu diperiksa secara terpisah. Penundaan pemrosesan gRPC juga dapat terlihat sebagai waktu tunggu atau koneksi yang terputus.
transactions/sec pada gRPC dan packets/sec pada UDP mengukur satuan yang berbeda pada tahap pemrosesan yang berbeda. Keduanya tidak dapat dibandingkan secara langsung untuk menghitung volume pengiriman atau tingkat kehilangan data.
Dari paket yang tiba hingga data yang dapat digunakan
Dengan penerima socket UDP standar, paket yang tiba melewati NIC, kernel, dan buffer penerimaan socket sebelum mencapai aplikasi. Jika pemrosesan tidak mampu mengimbangi kedatangan paket, paket dapat dibuang setelah mencapai host. Penghitung penerimaan antarmuka Linux mencakup paket yang dibuang pada tahap berikutnya, sehingga meningkatnya jumlah penerimaan saja tidak membuktikan bahwa paket telah sampai ke aplikasi.[4]
Satu antrean penerimaan atau inti CPU dapat sibuk meskipun penggunaan CPU secara keseluruhan rendah. Periksa antrean NIC, penempatan interupsi, dan kinerja inti tunggal. Di dalam aplikasi, pisahkan penerimaan dari pekerjaan lanjutan bila sesuai, dan hindari penguraian yang memakan banyak sumber daya serta pencatatan log yang berlebihan di dalam loop penerimaan. Buffer penerimaan yang lebih besar dapat menyerap lonjakan sementara; buffer tersebut tidak dapat mengatasi kekurangan kapasitas pemrosesan yang berkelanjutan.[5]
Shreds adalah fragmen data blok. Koreksi kesalahan maju (FEC) dapat memulihkan data yang hilang menggunakan data shreds dan coding shreds dari kelompok yang sama, tetapi rekonstruksi tetap memerlukan fragmen yang cukup. Bertambahnya paket duplikat tidak dapat menggantikan fragmen yang hilang.[6]
Bergantung pada implementasinya, penerima dapat merekonstruksi entri dari fragmen yang tersedia sebelum seluruh slot selesai.[9] Selain jumlah total paket, ukur Shreds unik yang valid, data yang telah direkonstruksi, dan waktu hingga aplikasi mengenali peristiwa yang dibutuhkan.
Ukur setiap tahap pada rentang waktu yang sama
Selaraskan tujuan, port, dan rentang waktu pengukuran pada kedua sisi. Pencatatan tahap berikut secara terpisah membantu mempersempit penyelidikan selanjutnya.
| Titik pengukuran | Hal yang dicatat | Hal yang dapat ditentukan |
|---|---|---|
| Pengirim | Catatan untuk tujuan yang ditargetkan dan definisi penghitung | Tahap pengiriman mana yang diamati |
| Titik masuk host penerima | Hasil tangkapan lalu lintas UDP target, statistik NIC, dan paket yang hilang saat penangkapan | Berapa banyak lalu lintas yang terlihat pada titik pengamatan tersebut |
| Sistem operasi dan socket | Kesalahan UDP, paket yang dibuang di buffer penerimaan, dan perubahan antrean | Apakah penerimaan menumpuk di dalam host |
| Rekonstruksi Shreds | Shreds unik yang valid, keberhasilan rekonstruksi, data yang hilang, dan kesalahan | Apakah paket menghasilkan data yang diperlukan |
| Aplikasi | Pekerjaan pemrosesan yang menumpuk dan stempel waktu deteksi untuk peristiwa yang sama | Apakah kecepatan kedatangan tercermin dalam aplikasi |
Jika hasil tangkapan menunjukkan sedikit paket, periksa terlebih dahulu filternya, antarmuka yang diamati, kehilangan paket saat penangkapan, dan paket yang dibuang di NIC. Sebagian penghitung sistem operasi mencakup seluruh host atau namespace jaringan; periksa cakupannya dan hubungkan dengan pengukuran dari aplikasi yang ditargetkan.[4][5]
Ubah pengaturan setelah mengidentifikasi tahap yang mengalami keterbatasan. Memperbesar buffer atau ring saja dapat memindahkan hambatan atau menambah waktu tunggu. Konfigurasi dan pemeriksaan penerima ERPC saat ini didokumentasikan di sini:
Pilih kebijakan operasional sekaligus servernya
Solana Foundation menjelaskan pentingnya kendali atas NIC, inti fisik, driver, dan jaringan bagi validator berkinerja tinggi. Persyaratan untuk validator penuh tersebut tidak seharusnya diterapkan secara menyeluruh pada setiap penerima Shreds. Aplikasi penerima membutuhkan konfigurasi yang sesuai dengan aliran data dan beban pemrosesannya sendiri.[7]
Menurunkan biaya atau konsumsi daya merupakan tujuan operasional yang wajar. Aplikasi HFT dan waktu nyata juga membutuhkan respons CPU yang cepat, kapasitas pemrosesan yang berkelanjutan, dan waktu tunggu jaringan yang singkat. Peralihan dari kondisi hemat daya ke kondisi aktif dapat melibatkan kompromi pada latensi.[8]
Selain model CPU dan jumlah inti, periksa cara sumber daya dibagi, cara beban berkelanjutan ditangani, ketentuan lalu lintas UDP, serta jalur jaringan yang sebenarnya.
ERPC mempertimbangkan aliran data dan lingkungan penerima secara bersamaan
ERPC menangani pemilihan pusat data yang dekat dengan infrastruktur Solana, jalur jaringan, perangkat keras, dan pengaturan operasional, serta menyediakan VPS dan Bare Metal bersama Shreds dan gRPC. Anda dapat memilih VPS untuk beban pemrosesan Anda dan membandingkannya dengan Bare Metal saat menginginkan sumber daya fisik eksklusif.
Memahami konfigurasi dan pengoperasian lingkungan yang kami sediakan juga membantu pemecahan masalah teknis. Kami dapat membandingkan catatan sisi pengirim dengan pengukuran penerima dan menentukan pemeriksaan konkret untuk jaringan, sistem operasi, atau aplikasi. Dalam permintaan dukungan yang dijelaskan di sini, kami memeriksa pengukuran sisi pengirim dan meminta pengukuran tambahan dari penerima.
Menilai aliran data, penempatan penerima, dan implementasi aplikasi secara bersamaan memudahkan identifikasi hal yang masih kurang antara layanan yang Anda pilih dan data yang Anda butuhkan.
Bandingkan lingkungan Anda saat ini dengan penagihan per jam
Jika Anda belum yakin dengan lingkungan penerima, cobalah server ERPC VPS atau Bare Metal dengan penagihan per jam dan bandingkan menggunakan aliran data serta aplikasi yang sama. Periksa dasbor untuk mengetahui harga, ketersediaan, dan ketentuan pemesanan terkini di wilayah pilihan Anda.
Mulailah dengan konfigurasi yang tersedia, lalu catat jumlah paket yang diterima, data yang direkonstruksi, pekerjaan pemrosesan yang menumpuk, dan stempel waktu deteksi untuk peristiwa yang sama. Saat membandingkan stempel waktu di antara host, periksa juga akurasi sinkronisasi jam. Ulangi pengujian pada waktu yang berbeda dan bandingkan di bagian mana dari jalur tersebut hasilnya berbeda. Gunakan pengukuran itu untuk memilih server dan pusat data yang sesuai dengan aplikasi Anda.
- VPS: https://erpc.global/id/vps/
- Bare Metal: https://erpc.global/id/baremetal/
- Dasbor: https://dashboard.erpc.global/id/
Artikel terkait
- Solana Stream SDK v4.0.0: https://erpc.global/id/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/id/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Discord resmi Validators DAO: https://discord.gg/C7ZQSrCkYR
Referensi teknis
- [1] Kuota bandwidth dan PPS AWS EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] Panduan Penggunaan UDP IETF, lonjakan lalu lintas: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] UDP Linux: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] TCP Linux: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] Kontrol aliran gRPC: https://grpc.io/docs/guides/flow-control/
- [4] Statistik antarmuka Linux: https://docs.kernel.org/networking/statistics.html
- [4] Perilaku penangkapan dan pembuangan paket libpcap: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Skalabilitas dalam tumpukan jaringan Linux: https://docs.kernel.org/networking/scaling.html
- [5] Buffer penerimaan socket Linux: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Investigasi paket UDP yang dibuang dari Red Hat: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Propagasi Blok Turbine Anza: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation, perangkat keras validator berkinerja tinggi: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Manajemen Waktu CPU Menganggur pada Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
