Solana VPS बनाम Bare Metal: CPU, UDP और नेटवर्क परीक्षण | ERPC

Solana स्ट्रीम जितना महत्वपूर्ण सर्वर भी है

तेज़ Solana स्ट्रीम का अर्थ नहीं कि ऐप को डेटा सही समय पर मिल ही जाएगा। कम CPU उपयोग और 1Gbps पोर्ट के बावजूद Shreds अधूरे रह सकते हैं या gRPC में देरी बढ़ सकती है। डेटा स्रोत से उपयोगी एप्लिकेशन आउटपुट तक पूरी प्रक्रिया मापनी चाहिए। यह लेख अज्ञात पहचान वाले मामलों, स्वतंत्र परीक्षणों और प्रकाशित बेंचमार्क पर आधारित है; किसी प्रदाता को अप्रमाणित कारण के लिए दोष नहीं देता।

तेज़ Solana में लगातार डेटा और अचानक बढ़े पैकेट आते हैं

Shreds और Yellowstone Geyser gRPC लगातार डेटा भेजते हैं, कभी छोटे bursts में। बैंडविड्थ, प्रति सेकंड पैकेट (PPS), RTT, jitter, loss और प्रोसेसिंग समय अलग माप हैं। कल्पना करें 4MB/s की दर 30 दिनों तक चलती है: लगभग 10.4TB डेटा, लेकिन औसत केवल 32Mbps। इससे 1Gbps का कम होना सिद्ध नहीं होता। UDP सीमा, साझा uplink, bursts और रिसीवर भी जांचें।

स्ट्रीम चालू है, लेकिन डेटा पूरा नहीं बनता

एक अज्ञात-नाम जांच में भेजने की ओर लगभग 3,400–3,900 UDP पैकेट/सेकंड देखे गए। अलग समय पर रिसीवर ने लगभग 13 पैकेट/सेकंड बताया। प्राप्त Shreds सही थे, पर पुनर्निर्माण के लिए पर्याप्त नहीं थे। उसी सर्वर पर gRPC काम कर रहा था। दोनों मापन अलग समय और स्थान के हैं, इसलिए निश्चित loss rate या कारण नहीं निकाला जा सकता। कुछ हजार PPS अपने आप में असामान्य बोझ भी नहीं है।

मशीन बदलने से पहले पैकेट कहाँ तक पहुँचे यह देखें

ऊपरी नेटवर्क नीति, DDoS सुरक्षा या virtualization host UDP को VM के पहले रोक सकते हैं। NIC के बाद kernel, socket buffer और ऐप भी पैकेट खो सकते हैं। पहले tcpdump से इंटरफेस देखें, फिर NIC काउंटर, UDP त्रुटि और ऐप कतार जांचें। XDP tcpdump से पहले पैकेट हटा सकता है। भेजने और पाने के समय, IP और पोर्ट का मिलान जरूरी है।

एक शहर का मतलब छोटा नेटवर्क मार्ग नहीं है

Frankfurt के दो सर्वर अलग सुविधाओं और नेटवर्कों में हो सकते हैं, जिनके बीच बाहरी transit हो। एक बाहरी होस्ट से Amsterdam के दो नजदीकी endpoints का RTT लगभग 11ms और 23ms था, जबकि उनके बीच केवल लगभग 0.1ms दूरी थी। दूसरी अवधि में upstream पर 5–8% पैकेट हानि और लगभग 5ms अतिरिक्त देरी देखी गई। ये एक विशिष्ट मार्ग की टिप्पणियाँ हैं, सभी प्रदाताओं का गुण नहीं।

डेटा स्रोत के पास एप्लिकेशन चलाएँ

आमतौर पर RPC प्रदाता डेटा देता है और hosting कंपनी सर्वर। ERPC Shreds, Geyser gRPC, RPC और VPS/Bare Metal को साथ डिजाइन करता है। समर्थित स्थानों पर पास के racks और स्थानीय नेटवर्क से अनावश्यक बाहरी मार्ग कम होते हैं। Zero-Distance Communication का अर्थ भौतिक दूरी या latency बिल्कुल शून्य होना नहीं है। वास्तविक मार्ग का परीक्षण जरूरी है।

देखें कि ऐप तक वास्तव में कितना डेटा पहुँचा

उसी Amsterdam endpoint के मिलते-जुलते Geyser gRPC subscription पर बाहरी hosting ने 3.7–4.2MiB/s और बढ़ता lag दर्ज किया। ERPC Frankfurt VPS के एक CPU core तक सीमित स्वतंत्र परीक्षण में 60 सेकंड के लिए औसतन 9.396MiB/s और लगभग 1,910 transactions/s मिले, लगातार बढ़ता lag नहीं था। समस्याग्रस्त मार्ग में TCP retransmissions भी दिखे। लेकिन host और client implementation अलग थे, इसलिए यह नियंत्रित A/B परीक्षण नहीं है। अलग HTTP/2 जांच में 16KiB window पर 2.7MB/s और बड़ी window पर अधिकतम 7.1MB/s मिला।

CPU के नाम से वास्तविक सीमाएँ नहीं दिखतीं

एक जैसी CPU पीढ़ी और vCPU संख्या के बावजूद boost, बिजली, तापमान और scheduler नीति अलग हो सकती है। AMD Core Performance Boost और Intel Turbo Boost को BIOS या host से बंद किया जा सकता है। चालू होने पर भी अधिकतम clock लगातार नहीं मिलता। VM को host के नियम दिखें, यह भी जरूरी नहीं। वास्तविक कार्य के तहत लगातार क्षमता मापें।

चार vCPU, प्रकाशित परीक्षण में 1.93 गुना अंतर

Amsterdam में AMD Turin 4-vCPU और Ubuntu 24.04 के ERPC प्रकाशित sysbench CPU परीक्षण में 7,850 बनाम 4,062 events/s दर्ज हुए, यानी उन शर्तों में लगभग 1.93×। उसी तुलना में memory bandwidth लगभग 3.2× और 4K random-read IOPS लगभग 16.6× बताए गए। इससे हर ऐप में ऐसा लाभ या केवल boost को कारण साबित नहीं होता।

डेटा सेंटर की अर्थव्यवस्था तकनीकी नीति तय करती है

बिजली, कूलिंग, racks, switches, नेटवर्क और संचालन महंगे हैं। साझा संसाधन साधारण ऐप के लिए उचित हैं। भारी Solana streaming और कम-latency कार्यों को लंबे समय तक CPU, PPS और uplink चाहिए। साझा बैंडविड्थ, प्रति-flow सीमा, DDoS और ऊर्जा बचत दूसरे उपयोगों में उचित हो सकते हैं। सवाल प्रदाता को गलत कहना नहीं, अपनी जरूरत से मेल देखना है।

क्लाउड ट्रांसफर खर्च भी देखें

लगातार stream समय के साथ TB में बढ़ते हैं। कुछ cloud पर internet ingress मुफ्त होता है, लेकिन egress, zone और service के बीच ट्रांसफर पर शुल्क लग सकता है। योग्य ERPC योजनाएँ प्लेटफॉर्म के भीतर डेटा और बाहरी ट्रांसफर को अलग मानती हैं; वर्तमान शर्तें जांचें। कुल डेटा मार्ग की लागत देखें, केवल VM का किराया नहीं।

वर्कलोड के अनुसार VPS या Bare Metal लें

हल्के RPC के लिए EPYC VPS पर्याप्त हो सकता है। लंबे gRPC विश्लेषण के लिए CPU व मेमोरी क्षमता चाहिए। कम-latency Shreds UDP में UDP नीति, PPS, bursts, नजदीकी placement और detection time देखें। भौतिक CPU या NIC का विशेष उपयोग चाहिए तो Bare Metal उचित है, मगर हर स्थिति में स्वतः तेज़ नहीं। कई VPS में काम बाँटना भी प्रभावी हो सकता है। समान ऐप, फ़िल्टर और समय में Shreds, reconstruction, lag, retransmissions और p95/p99 की तुलना करें।

लंबी सदस्यता से पहले मापें

Linux पर tcpdump, nstat, ip -s link, ethtool -S, ss -tin और lscpu से बिना सेटिंग बदले प्रारंभिक जांच कर सकते हैं। उदाहरण IP व इंटरफेस बदलें और समय के साथ काउंटर का बदलाव देखें। केवल lscpu से hypervisor की boost नीति प्रमाणित नहीं होती। ERPC योग्य VPS और Bare Metal को उपलब्धता अनुसार घंटे के हिसाब से देता है। ऐसा सर्वर चुनें जो जरूरी डेटा समय पर उपयोगी बना दे।

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