ستاسو ډاونلوډ ګړندی دی، نو ولې هر کلیک ورو ښکاري؟
لوی لیږد کولی شي په بشپړ سرعت روان وي کله چې زنګونه او کلیکونه وروسته پاتې شي. د تګ راتګ وخت، دوامداره کچه او د بار لاندې ځنډ د درې جلا پوښتنو په توګه وګورئ.
یو لوی فایل په ګړندي ډول ډاونلوډ کول او بیا هر کلیک ورو احساسول یو تضاد نه دی۔ ظرفیت وایي چې په یوه ثانیه کې څومره ښکته پورته کیدای شي؛ د تګ راتګ وخت وایي چې یو تبادله تر هغه څه ګټور پیښیدو مخکې څومره دوام کوي۔ لومړی ښه کول دویم ته هېڅ نه کوي، او دویم هغه شی دی چې سړی یې د ټایپ کولو، کلیک کولو یا خبرو پر مهال احساسوي۔ شکایت وګورئ، نه اړیکه۔
ګړندی فایل، ورو کلیک: دوه بېلې شمېرې
د ډله ییز لیږد معلومات په دوامداره خوځښت کې ساتي، نو دا کولی شي روغه کچه راپور کړي حتی کله چې هر یو غوښتنه انتظار کوي۔ ډېرې ازموینې په یو وخت کې څو اړیکې هم پرانیزي، چې ټوله شمېره لوړوي پداسې حال کې چې یوه غوښتنه ورو پاتې کیږي۔ دواړه پایلې سره سمون لري، او لوړه شمېره هغه کاروونکي ته ویل چې د ځنډ شکایت کوي، د باور له لاسه ورکولو لاره ده۔
د پاڼې لوډ کیدل د کوچنیو تبادلو یوه زنځیره ده: د نوم حل، د اړیکې جوړول، یوه غوښتنه، یو ځواب او بیا تړلې غوښتنې۔ هر ګام بیا د تګ راتګ وخت ورکوي، نو د ډېر ځنډ لاره حتی کله چې ډېر ظرفیت ولري ورو ښکاري۔
ټنل خپله سفر او پروسس اضافه کوي، او لاره د نقشې پر لیبل مهمه ده۔ په یوه هیواد کې دوه وتل کیدای شي یوې منزل ته ډېر بېلې لارې ولري۔ د شلو میلی ثانیو توپیر د پاڼې احساس بدلولو لپاره کافي دی، که څه هم د تګ راتګ شمېره په سختۍ خوځوي۔ له همدې امله د وتلو غوره کول باید د بیرغ آیکون پر ځای د ځنډ نمونې تعقیب کړي۔
شکایت وګورئ، نه اړیکه
هغه اندازه غوره کړئ چې د کاروونکي وینا سره سمه وي۔ ورو ډاونلوډ سمې لوري ته دوامداره کچه غواړي؛ ناوخته زنګ د هغه اپلیکیشن خپله احصایه غواړي؛ ورو پیلیدونکې پاڼه د نوم حل او جوړولو وختونه غواړي۔
ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4لومړی حکم د وړاندوینې وړ ځواب ورکوونکي هوسټ ته د تګ راتګ نمونه ورکوي، دویم د یوې اړیکې لپاره د لومړي بایټ تر وخت او دوامداره کچه راپور کوي، او دریم د څلورو موازي جریانونو سره ټوله کچه اندازه کوي۔ هغوی د ورځې په هماغه وخت کې هماغه منزل ته وچلوئ، ځکه چې د سهار نمونې د ماښام نمونې سره پرتله اندازه نه، کیسه جوړوي۔
د وتلو پرتله کولو پر مهال منزل ثابت وساتئ۔ سرور او ټنل دواړه بدلول یو متغیر په دوو بدلوي، او پایله نشي ویلای چې کوم مهم و۔ هر وتل لږ تر لږه درې ځله وچلوئ، ځکه چې یوازې نمونه ډېری د لارې بدلون یا د یوې شورې دقیقې په وخت کې رالویږي۔ منځنی له غوره حالت څخه ډېر ګټور دی۔
ICMP د ځواب پر ځای د نښې په توګه وګورئ۔ ځواب ورکوونکی هوسټ کیدای شي د اکو غوښتنې په هغه لار څخه بېلې لارې سمبال کړي چې ستاسو اپلیکیشن یې کاروي، او یو ورک شوی ځواب دا ثبوت نه دی چې هر اپلیکیشن پاکټونه ورکوي۔
د بار لاندې ځنډ د قطار ستونزه ده
هغه بڼه چې خلک ډېر ګډوډوي هغه اړیکه ده چې بې کاره وي ښه احساسیږي او د بیک اپ پر مهال بې کاره وي۔ دا قطار دی، ظرفیت نه۔ ډکه پورتنۍ لاره د هر بل پاکټ مخې ته بفر جوړوي، نو د کیلي فشار د پورته کولو یوې برخې شاته انتظار کوي۔
ping -c 20 10.60.0.5 & iperf3 -c 10.60.0.5 -t 20 -R -b 20M
لومړی حکم په شالید کې د ځنډ نمونې اخلي کله چې دویم مخالف لور ډکوي۔ که د لیږد پر مهال د ping وختونه ټوپ ووهي او بیا ښه شي، تاسو د لارې خرابي موندنې پر ځای bufferbloat بیا تولید کړی دی۔ حل معمولاً د قطار مدیریت تنظیم، ټیټه شالید کچه، یا د لوی لیږد له تعاملي لارې لرې کول دي۔
د اختیاري شالید ترافیک کمول ډېری وخت د وتلو هیواد بدلولو څخه ډېر مرسته کوي۔ دا ارزانه هم دی، بدلیدونکی او په یوه دقیقه کې ازمویل کیدای شي۔ که قطار سمبالیدای نشي، لوی پورته کول د کاري ساعتونو بهر مهال وټاکئ، او که باید په ورځ کې روان وي، د هغوی کچه محدوده کړئ۔ کله چې روټر ملاتړ وکړي، د قطار مدیریت تنظیم غوره حل دی۔
یو شی بدل کړئ او ورته د ورته سره پرتله کړئ
د ډېر بې کاره ځنډ لپاره منزل ثابت وساتئ او وتل پرتله کړئ، بیا د غوره نوماند لپاره لارې پرتله کړئ۔ د ټیټ ثابت تګ راتګ لپاره پر ځای ظرفیت، د سرور بار او د کاروونکي پروسس وګورئ، ځکه هغه بېلې حدونه دي۔
څه مو اندازه کړل، د کوم منزل پر وړاندې، په کوم وخت او د کومو تنظیماتو سره ولیکئ۔ پرته له هغو څلورو حقایقو پرتله تکراریدای نشي، او بل کس له صفر څخه پیل کوي۔
بیا د ټکټ ادعا سره وسیله سمه کړئ۔ "ورو انټرنیټ" اندازه نه ده؛ "دې هوسټ ته لومړي بایټ 900 ms وخت واخیست کله چې تګ راتګ ښه و" اندازه ده، او دا مستقیم ظرفیت ته نه، ځنډ ته اشاره کوي۔