iperf3 का उपयोग करके नेटवर्क थ्रूपुट को मापना

7 min

language: ja bn en es hi pt ru zh-cn zh-tw

नमस्ते, मैं अक्षम हूँ।

परिचय

मैंने एक बारElasticsearch के साथ मेट्रिक डेटा प्राप्त करने और उसेkibana के साथ विज़ुअलाइज़ करने का प्रयास किया था, लेकिन यह घर पर उपयोग करने के लिए पर्याप्त इको-फ्रेंडली नहीं था। वास्तव में, भले ही यह एक वितरित प्रणाली है, इसने इतने अधिक संसाधन खाए कि न तो मेरा दिमाग और न ही मेरा कमजोर होम सर्वर इसे सहन कर सका, इसलिए मैं अन्य तरीकों की तलाश कर रहा हूँ।
OOM Killer को ट्रिगर करना वास्तव में कंप्यूटर के लिए बहुत दुखद है।
हालांकि मेरे पास पहले से ही अन्य वैकल्पिक तरीके तैयार हैं, लेकिन अगर मुझे केवल भेजने के लिए मेट्रिक्स की आवश्यकता है, तो मैं सबसे पहले भेजने वाले डेटा पर विचार करूँगा।

सबसे पहले, एप्लीकेशन लेयर से पहले निचली लेयर से शुरू करते हैं।

iperf3 इंस्टॉल करें

इस बार, मैं अपने ThinkPad X1C@Artix Linux को प्रेषक के रूप में और अपने होम सर्वर@Devuan को प्राप्तकर्ता के रूप में उपयोग करके काम करूँगा।

ThinkPad X1C@Artix Linux

$ sudo pacman -S iperf3

होम सर्वर@Devuan

$ sudo apt install iperf3
$ sudo ufw allow 5201/tcp
$ sudo ufw reload

apt पैकेज काiperf3 एकTUI लाएगा जिसमें पूछा जाएगा कि क्या इसे डेमॉन के रूप में शुरू करना है, लेकिन इस बार मैंn चुनूँगा।

अब तैयारी पूरी हो गई है।

मापन

सर्वर साइड पर सुनें।

होम सर्वर@Devuan

$ iperf -s

क्लाइंट साइड से भेजें। यह एक वाई-फाई वातावरण है जिसके बीच में एक दीवार है, इसलिए कृपया इसे सहन करें... इसके विपरीत, शायद कम गुणवत्ता वाला डेटा प्राप्त करना वास्तव में मेरे पक्ष में काम कर रहा है।

ThinkPad X1C@Artix Linux

$ iperf3 -c DevuanSrvIP
Connecting to host DevuanSrvIP, port 5201
[  5] local 192.168.10.118 port 41000 connected to DevuanSrvIP port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  10.8 MBytes  90.1 Mbits/sec    0    406 KBytes       
[  5]   1.00-2.00   sec  9.00 MBytes  75.5 Mbits/sec    0    484 KBytes       
[  5]   2.00-3.00   sec  9.38 MBytes  78.6 Mbits/sec    1    485 KBytes       
[  5]   3.00-4.00   sec  7.25 MBytes  60.8 Mbits/sec    0    167 KBytes       
[  5]   4.00-5.00   sec  8.25 MBytes  69.2 Mbits/sec    0    494 KBytes       
[  5]   5.00-6.00   sec  8.62 MBytes  72.3 Mbits/sec    0    496 KBytes       
[  5]   6.00-7.00   sec  9.38 MBytes  78.6 Mbits/sec    1    499 KBytes       
[  5]   7.00-8.00   sec  9.50 MBytes  79.7 Mbits/sec    0    501 KBytes       
[  5]   8.00-9.00   sec  7.62 MBytes  64.0 Mbits/sec    1    505 KBytes       
[  5]   9.00-10.00  sec  7.62 MBytes  63.9 Mbits/sec    0    508 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  87.4 MBytes  73.3 Mbits/sec    3             sender
[  5]   0.00-10.02  sec  85.3 MBytes  71.5 Mbits/sec                  receiver

iperf Done.

केवल इसी से, TCP संचार के विंडो नियंत्रण के तहत रिट्राई के रूप मेंRetr और विंडो आकार के रूप मेंCwnd से नेटवर्क गुणवत्ता का मूल्यांकन किया जा सकता है, और भिन्नताओं से गुणवत्ता का मूल्यांकन करना भी संभव लगता है।
यदि इसे सरलता से किया जाए, तो केवलsender को निकालें और

$ iperf3 -c DevuanSrvIP | grep "sender" 
[  5]   0.00-10.00  sec  83.8 MBytes  70.2 Mbits/sec    1             sender

यहां से, इसेawk को पाइप करके आवश्यक जानकारी को मेट्रिक डेटा के रूप में भेजना भी संभव लगता है।

निष्कर्ष

अन्य बातों में, डिस्क I/O मेट्रिक डेटा भी दिलचस्प लगता है, लेकिन नियमित रूप से तीव्र डिस्क थ्रूपुट को मापना केवल एक परेशानी होगी, इसलिए मुझे लगता है कि जितना संभव हो सके उतनी कम जानकारी एकत्र करना बेहतर है। यह ऐसी बात नहीं है जिस पर मैं आमतौर पर ध्यान देता हूँ, लेकिन यह देखना दिलचस्प होगा कि I/O प्रतीक्षाएँ असामान्य रूप से कब होती हैं।
मुझे आश्चर्य है कि एप्लिकेशन मेट्रिक डेटा कितना एकत्र किया जाना चाहिए? मुझे लगता है कि अवलोकन का दायरा काफी व्यापक है।
चूंकि प्रत्येक सॉफ़्टवेयर का अपना डिज़ाइन दर्शन होता है, इसलिए यह समझना आवश्यक है कि वहां से कितना आउटपुट उत्पन्न किया जा सकता है। जब तक जानकारी बाहरी रूप से एकत्र की जाती है, ऐसा लगता है कि मॉड्यूल को डेटा आउटपुट करने के लिए पेश किया जाता है? यह एक छवि है, लेकिन ऐसा लगता है कि मुख्य रूप से केवल OS साइड से एकत्र किए जा सकने वाले डेटा का उपयोग करना अधिक लचीला होगा।
दूसरे शब्दों में, यदि सिस्टम कॉल को CPU को निर्देश दिए जा रहे हैं, तो ऐसा लगता है कि उन्हें किसी तरह से ट्रेस करना संभव हो सकता है, लेकिन वह एक और कहानी है...

वैसे,Elasticsearch, जिसे मैंने अतीत में विभिन्न कारणों से इंस्टॉल किया है, काफी मांग वाला है जब तक कि आपके पास ऐसा वातावरण न हो जहाँ आप जितने चाहें उतने संसाधनों का उपयोग कर सकें! तो, अगर मुझे कभी ऐसा वातावरण मिलता है, तो मैं इसे फिर से आज़माऊँगा।
हालांकि, इस प्रकार के इन-मेमोरी डेटाबेस के तत्वों को शामिल करने वाले OSS सॉफ़्टवेयर बहुत उत्कृष्ट हैं, इसलिए यदि मैं इसका उपयोग करता हूँ, तो मुझे इसे पेश करने से पहले यह ठीक से तय करना होगा कि क्या यह अपने उद्देश्य और लागत के स्तर से मेल खाता है, अन्यथा, मैं केवल एक ऐसा व्यक्ति बन सकता हूँ जो RAM को भारी मात्रा में खपत होते हुए देखता है। इसलिए मैं सावधान रहूँगा।
फिर मिलते हैं। धन्यवाद।

Related Posts