Kalkulahin ang kapaki-pakinabang na rate ng transfer na kailangan ng iyong window ng paghahatid, pagkatapos sukatin ang buong landas. Ang kapasidad ng port, round-trip time, pag-uugali ng TCP, storage at pagproseso ng aplikasyon ay nakakaapekto sa resulta. Gumamit ng kontroladong mga pagsubok na may makatotohanang concurrency at ulitin ang mga ito sa aktwal na aplikasyon bago pumili ng tier ng network.
Gawing rate ang window ng paghahatid
Magsimula sa isang dami ng kapaki-pakinabang na data ng aplikasyon at ang oras na magagamit upang maihatid ito. Gamit ang decimal na mga yunit, ang paglilipat ng 2 TB sa loob ng dalawang oras ay nangangailangan ng humigit-kumulang 278 MB bawat segundo ng payload, o 2.22 Gbps, bago isaalang-alang ang protocol overhead at mga pagkaantala. Ang aritmetika ay isang halimbawa ng pagpaplano, hindi isang nasusukat na resulta ng serbisyo.
Isama ang mga transfer na nagsasapawan. Ang isang naka-iskedyul na export, mga download ng customer at mga upload ng backup ay maaaring magbahagi ng mga resource kahit na ang kanilang buwanang kabuuan ay mukhang katamtaman. Sumulat ng modelo ng abalang panahon, hindi lamang buwanang average. Tukuyin kung aling direksyon ang mahalaga at kung ang isang nabigong transfer ay dapat magsimula muli o maaaring magpatuloy; ang pag-uugaling iyon ay nakakaapekto sa dami ng trabahong ginagawa ng system.
Ihiwalay ang kapasidad ng port mula sa kapaki-pakinabang na throughput
Ang isang port ng server ay naglalarawan ng kapasidad ng link. Ang kapaki-pakinabang na throughput ay naglalarawan ng data na inihatid ng iyong aplikasyon sa isang naobserbahang agwat. Ang encryption, protocol framing, retransmission, aktibidad ng storage at trabaho sa receiver ay sumasakop sa mga bahagi ng landas na iyon. Ang isang nakalistang 10 Gbps port ay samakatuwid ay hindi nagpapatunay na ang isang aplikasyon ay patuloy na maghahatid ng 10 Gbps ng payload.
Ang IETF RFC 6349 ay partikular na nagtatangi ng pagsubok sa landas ng network mula sa pagsusuri ng pagganap ng TCP. Gamitin ang paghihiwalay na ito sa iyong sariling diagnosis. Kumpirmahin muna na ang mga endpoint at ruta ay angkop, pagkatapos imbestigahan ang transport at aplikasyon. Ang pagtaas ng biniling port ay hindi nagwawasto sa isang receiver na mabagal magsulat ng data o isang aplikasyon na nagpoproseso ng isang request sa isang pagkakataon.
Unawain kung bakit mahalaga ang round-trip time
Kinokontrol ng TCP kung gaano karaming data ang maaaring manatili sa paglipad bago bumalik ang mga acknowledgement. Ang bandwidth-delay product ay nagbibigay ng kapaki-pakinabang na sukat para dito: rate na pinarami ng round-trip time. Ang isang hypothetical na 10 Gbps na landas na may 40 millisecond ng round-trip delay ay kumakatawan sa humigit-kumulang 50 MB na nasa paglipad. Ipinapaliwanag ng kalkulasyong ito kung bakit ang latency at pag-uugali ng transport ay kabilang sa pagpaplano ng mataas na bilis.
Ang resulta ay hindi isang tagubilin na maglapat ng arbitraryong setting ng socket. Ang mga operating system, congestion control, napagkasunduang window at ang aktwal na landas ay nakakaimpluwensya sa pag-uugali. I-verify ang kasalukuyang dokumentasyon ng software at suriin ang mga pagsukat bago mag-tune. Ang mas maraming parallel na koneksyon ay maaaring mapabuti ang pinagsama-samang throughput sa ilang mga pagkakataon, ngunit maaari rin nilang itago ang pag-uugali ng indibidwal na transfer na pinagkakatiwalaan ng iyong aplikasyon.
Bumuo ng kontroladong test matrix
Gumamit lamang ng mga endpoint na pagmamay-ari mo o awtorisado kang subukan. Sumang-ayon sa window ng pagsubok at rate upang hindi maabala ng pagsasanay ang normal na serbisyo. Ang mga tool tulad ng iperf3 ay nagbibigay ng maaaring i-configure na direksyon, tagal at parallel na stream; tinutukoy ng opisyal na dokumentasyon ang mga kontrol na iyon. Itala ang bersyon, mga endpoint, konteksto ng ruta at mga setting kasama ng resulta upang maaaring kopyahin ito ng ibang operator.
Magsimula sa isang solong flow, pagkatapos magdagdag ng representatibong concurrency. Patakbuhin ang parehong direksyon kung ang aplikasyon ay umaasa sa pareho. Ang halimbawang matrix na ito ay naghihiwalay ng mga tanong na paghahaluin ng isang solong headline na resulta. Itago nang pribado ang mga raw na resulta kapag naglalantad ang mga ito ng panloob na address o detalye ng operasyon, at i-publish lamang ang mga pagsukat na kailangan para sa desisyon.
| Pagsubok | Ano ang sinisiyasat nito | Ano ang hindi nito pinapatunayan |
|---|---|---|
| Isang transport flow | Pag-uugali ng single-flow na landas | Pinagsama-samang paghahatid ng aplikasyon |
| Ilang parallel na flow | Concurrency at pinagsama-samang mga limitasyon | Rate ng transfer ng isang customer |
| Transfer ng aplikasyon | Storage, protocol at software nang magkasama | Pagganap para sa bawat dataset |
| Ulit ng abalang panahon | Pagkakaiba-iba sa ilalim ng makatotohanang aktibidad | Isang permanenteng garantiya ng throughput |
Tingnan ang mga endpoint habang nagsubok
Itala ang paggamit ng CPU, pressure sa memory, aktibidad ng storage at mga error counter sa magkabilang dulo. Ang resulta ng transfer na walang obserbasyon sa endpoint ay maaaring mag-iwan sa tunay na hadlang na hindi nakikita. Suriin kung ang isang proseso o CPU ay saturated habang ang iba ay idle. Iwasan ang pagbabago ng ilang setting nang sabay, dahil nagpapahirap itong tukuyin kung aling pagsasaayos ang nakatulong.
Ihiwalay ang isang memory-backed na pagsubok mula sa isa na nagbabasa at nagsusulat ng tunay na data. Ang una ay makakatulong sa pagsisiyasat ng landas ng transport; ang huli ay sumasalamin sa mas maraming trabaho ng aplikasyon. Kung ang mga resulta ay lubhang magkaiba, suriin ang storage at pagproseso sa halip na ituring ang memory-backed na bilang bilang isang pangako sa paghahatid. Ang parehong pagsukat ay maaaring maging kapaki-pakinabang kapag malinaw ang kanilang saklaw.
Subukan ang aplikasyon gamit ang makatotohanang payload
Ang isang HTTP export, encrypted replication stream at file-transfer session ay may magkaibang pattern ng pagproseso. Gumamit ng representatibong laki ng file, rate ng request at setting ng encryption. Isama ang oras na ginugol sa paghahanda ng data bago ipadala ang unang byte kapag hinihintay ng user ang hakbang na iyon. Ibahin ang latency ng unang tugon mula sa oras ng pagkumpleto sa halip na iulat ang isa bilang ang iba.
Ulitin ang pagsubok sa sapat na mga agwat upang makita ang pagkakaiba-iba, at panatilihin ang baseline bago baguhin ang configuration. Para sa hypothetical na 2 TB export, ihambing ang aktwal na oras ng pagkumpleto sa dalawang oras na window at mag-iwan ng margin para sa mga pagkaantala. Pumili ng pagpapabuti laban sa naobserbahang bottleneck sa halip na paramihin ang kapasidad ng port nang walang dahilan.
Gamitin ang resulta upang pumili ng configuration
Ang kapaki-pakinabang na output ay isang kinakailangan sa resource na may ebidensya: isang nasusukat na rate ng payload, katanggap-tanggap na oras ng pagkumpleto, inaasahang concurrency at kilalang yugto ng paglilimita. Ihambing ang mga variant ng SwissOctet network laban sa kinakailangang iyon, kabilang ang allowance sa trapiko at ang CPU at mga spesipikasyon ng storage. Ang lokasyon lamang ay hindi tumutukoy sa ruta o end-to-end latency sa bawat receiver.
Panatilihin ang pamamaraan ng pagsubok pagkatapos ng deployment. Gamitin muli ito kapag lumaki ang mga dataset, nagbago ang software o lumipat ang mga user sa iba't ibang network. Ang isang maaaring ulitin na baseline ay nagpapadali sa diagnosis ng isang insidente sa pagganap at nagbibigay ng mas matibay na dahilan para baguhin ang isang configuration kaysa sa isang nakahiwalay na speed test o isang inaanunsyong maximum.
Ang iyong praktikal na checklist.
- Kalkulahin ang rate ng payload mula sa volume at deadline.
- I-modelo ang nagsasapawang mga transfer at direksyon.
- Sumang-ayon sa mga awtorisadong endpoint ng pagsubok at mga limitasyon.
- Ihambing ang isang flow, concurrency at mga pagsubok ng aplikasyon.
- Obserbahan ang magkabilang endpoint habang nagsubok.
- Panatilihin ang isang maaaring ulitin na baseline at kapaki-pakinabang na margin.
Ang mga detalyeng mahalaga.
Laging inaayos ba ng mas malaking TCP window ang mabagal na transfer?+
Hindi. I-diagnose muna ang landas at mga endpoint. Ang storage, CPU, pagkawala at pag-uugali ng aplikasyon ay maaaring mangibabaw, at ang pag-tune ng transport ay dapat umangkop sa aktwal na system.
Bakit subukan ang isang solong flow at ilang flow?+
Sumasagot sila sa magkaibang mga tanong. Ang pinagsama-samang kapasidad ay maaaring mas mataas kaysa sa rate ng isang transfer; ang concurrency ng aplikasyon ay tumutukoy kung aling resulta ang mahalaga.
Maaari ba akong magpatakbo ng capacity test laban sa anumang pampublikong server?+
Gumamit ng mga endpoint na kontrolado mo o may pahintulot kang subukan. Sumang-ayon sa tagal, rate at timing upang hindi maabala ng pagsukat ang mga walang kaugnayang serbisyo.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- IETF RFC 6349: Balangkas para sa pagsubok ng TCP throughput datatracker.ietf.org
- ESnet: Invoking iperf3 software.es.net
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.