Laske hyödyllinen siirtonopeus, jonka toimitusikkunasi vaatii, ja mittaa sitten koko polku. Portin kapasiteetti, edestakainen viive, TCP-käyttäytyminen, tallennus ja sovelluksen käsittely vaikuttavat kaikki tulokseen. Käytä hallittuja testejä realistisella samanaikaisuudella ja toista ne todellisen sovelluksen kautta ennen verkkotason valintaa.
Muunna toimitusikkuna nopeudeksi
Aloita hyödyllisen sovellusdatan määrästä ja käytettävissä olevasta toimitusajasta. Desimaaliyksiköitä käyttäen 2 TB siirtäminen kahdessa tunnissa vaatii noin 278 MB sekunnissa hyötykuormaa eli 2.22 Gbps, ennen kuin otetaan huomioon protokollan yleiskustannukset ja keskeytykset. Laskelma on suunnitteluesimerkki, ei mitattu palvelutulos.
Sisällytä päällekkäiset siirrot. Ajoitettu vienti, asiakkaiden lataukset ja varmuuskopioiden lataukset voivat jakaa resursseja, vaikka niiden kuukausittaiset kokonaismäärät näyttäisivät vaatimattomilta. Kirjoita ruuhka-ajan malli, ei vain kuukausikeskiarvoa. Määritä, mikä suunta on merkityksellinen ja onko epäonnistunut siirto aloitettava alusta vai voiko se jatkua; tämä toiminta vaikuttaa järjestelmän suorittaman työn määrään.
Pidä portin kapasiteetti erillään hyödyllisestä läpäisystä
Palvelimen portti kuvaa yhteyden kapasiteettia. Hyödyllinen läpäisy kuvaa dataa, jonka sovelluksesi toimittaa havaitun ajanjakson aikana. Salaus, protokollan kehystys, uudelleenlähetys, tallennustoiminta ja vastaanottajan työ vievät osan kyseisestä polusta. Lueteltu 10 Gbps -portti ei siis osoita, että sovellus toimittaisi jatkuvasti 10 Gbps hyötykuormaa.
IETF RFC 6349 erottaa nimenomaisesti verkkopolun testaamisen TCP-suorituskyvyn tarkastelusta. Käytä tätä erottelua omassa diagnosoinnissasi. Vahvista ensin, että päätepisteet ja reitti ovat sopivia, ja tutki sitten siirtokerrosta ja sovellusta. Ostetun portin kasvattaminen ei korjaa vastaanottajaa, joka kirjoittaa dataa hitaasti, eikä sovellusta, joka käsittelee yhden pyynnön kerrallaan.
Ymmärrä, miksi edestakainen viive on tärkeä
TCP säätelee, kuinka paljon dataa voi olla matkalla ennen kuittausten palaamista. Kaistanleveys-viive-tulo antaa tälle hyödyllisen mittakaavan: nopeus kerrottuna edestakaisella viiveellä. Hypoteettinen 10 Gbps -polku, jonka edestakainen viive on 40 millisekuntia, edustaa noin 50 MB:tä matkalla. Tämä laskelma selittää, miksi latenssi ja siirtokäyttäytyminen kuuluvat suurnopeussuunnitteluun.
Tulos ei ole ohje soveltaa mielivaltaista pistokeasetusta. Käyttöjärjestelmät, ruuhkautumisen hallinta, neuvotellut ikkunat ja todellinen polku vaikuttavat toimintaan. Vahvista nykyinen ohjelmistodokumentaatio ja tarkastele mittauksia ennen viritystä. Useammat rinnakkaiset yhteydet voivat parantaa kokonaisläpäisyä joissakin tilanteissa, mutta ne voivat myös peittää yksittäisen siirron toiminnan, josta sovelluksesi on riippuvainen.
Rakenna hallittu testimatriisi
Käytä vain päätepisteitä, jotka omistat tai joiden testaamiseen sinulla on lupa. Sovi testi-ikkunasta ja nopeudesta, jotta harjoitus ei häiritse normaalia palvelua. Työkalut, kuten iperf3, tarjoavat määritettävän suunnan, keston ja rinnakkaiset virrat; virallinen dokumentaatio määrittelee nämä hallintakeinot. Kirjaa versio, päätepisteet, reittikonteksti ja asetukset tuloksen kanssa, jotta toinen operaattori voi toistaa sen.
Aloita yhdestä virrasta ja lisää sitten edustava samanaikaisuus. Aja molemmat suunnat, jos sovellus on riippuvainen molemmista. Tämä havainnollistava matriisi erottaa kysymykset, jotka yksi otsikkotulos sekoittaisi yhteen. Pidä raakatulokset yksityisinä, kun ne paljastavat sisäisiä osoitteita tai toiminnallisia yksityiskohtia, ja julkaise vain päätöksentekoon tarvittavat mittaukset.
| Testi | Mitä se tutkii | Mitä se ei todista |
|---|---|---|
| Yksi siirtovirta | Yhden virran polun toiminta | Sovelluksen kokonaistoimitus |
| Useita rinnakkaisia virtoja | Samanaikaisuus ja kokonaisrajoitukset | Yhden asiakkaan siirtonopeus |
| Sovellussiirto | Tallennus, protokolla ja ohjelmisto yhdessä | Suorituskyky jokaiselle tietojoukolle |
| Ruuhka-ajan toisto | Vaihtelu realistisen toiminnan aikana | Pysyvä läpäisytakuu |
Tarkkaile päätepisteitä testin aikana
Kirjaa CPU-käyttö, muistipaine, tallennustoiminta ja virhelaskurit molemmissa päissä. Siirtotulos ilman päätepistehavaintoja voi jättää todellisen rajoitteen näkymättömäksi. Tarkista, onko yksi prosessi tai CPU kyllästynyt, kun muut ovat joutilaina. Vältä useiden asetusten muuttamista kerralla, koska se vaikeuttaa sen tunnistamista, mikä säätö auttoi.
Erota muistipohjainen testi testistä, joka lukee ja kirjoittaa todellista dataa. Edellinen voi auttaa tutkimaan siirtopolkua; jälkimmäinen heijastaa enemmän sovelluksen työtä. Jos tulokset eroavat jyrkästi, tarkastele tallennusta ja käsittelyä sen sijaan, että pitäisit muistipohjaista lukua toimitulupauksena. Molemmat mittaukset voivat olla hyödyllisiä, kun niiden laajuus on selvä.
Testaa sovellusta realistisilla hyötykuormilla
HTTP-viennillä, salatulla replikointivirralla ja tiedostonsiirtoistunnolla on erilaiset käsittelymallit. Käytä edustavia tiedostokokoja, pyyntönopeuksia ja salausasetuksia. Sisällytä aika, joka kuluu datan valmisteluun ennen ensimmäisen tavun lähettämistä, kun käyttäjä odottaa tätä vaihetta. Erota ensimmäisen vastauksen latenssi valmistumisajasta sen sijaan, että raportoisit toisen toisena.
Toista testi riittävän monella aikavälillä vaihtelun näkemiseksi ja pidä lähtötaso ennen kokoonpanon muuttamista. Hypoteettisen 2 TB -viennin osalta vertaa todellista valmistumisaikaa kahden tunnin ikkunaan ja jätä marginaalia keskeytyksille. Valitse parannus havaittua pullonkaulaa vasten sen sijaan, että kertoisit portin kapasiteettia ilman syytä.
Käytä tulosta kokoonpanon valintaan
Hyödyllinen tulos on resurssivaatimus, jolla on näyttö: mitattu hyötykuormanopeus, hyväksyttävä valmistumisaika, odotettu samanaikaisuus ja tunnettu rajoittava vaihe. Vertaa SwissOctet-verkkovaihtoehtoja kyseiseen vaatimukseen, mukaan lukien liikennemäärä sekä CPU- ja tallennusmäärittelyt. Pelkkä sijainti ei määritä reittiä eikä päästä päähän -latenssia jokaiseen vastaanottajaan.
Säilytä testimenettely käyttöönoton jälkeen. Käytä sitä uudelleen, kun tietojoukot kasvavat, ohjelmisto muuttuu tai käyttäjät siirtyvät eri verkkoihin. Toistettava lähtötaso helpottaa suorituskykyhäiriön diagnosointia ja tarjoaa perustellumman syyn kokoonpanon muuttamiseen kuin yksittäinen nopeustesti tai mainostettu enimmäisnopeus.
Käytännön tarkistuslistasi.
- Laske hyötykuormanopeus määrästä ja määräajasta.
- Mallinna päällekkäiset siirrot ja suunta.
- Sovi valtuutetuista testipäätepisteistä ja rajoituksista.
- Vertaa yhtä virtaa, samanaikaisuutta ja sovellustestejä.
- Tarkkaile molempia päätepisteitä testauksen aikana.
- Säilytä toistettava lähtötaso ja hyödyllinen marginaali.
Olennaiset yksityiskohdat.
Korjaako suurempi TCP-ikkuna aina hitaan siirron?+
Ei. Diagnosoi ensin polku ja päätepisteet. Tallennus, CPU, häviöt ja sovelluksen toiminta voivat olla hallitsevia, ja siirtokerroksen virityksen on sovittava todelliseen järjestelmään.
Miksi testata yhtä virtaa ja useita virtoja?+
Ne vastaavat eri kysymyksiin. Kokonaiskapasiteetti voi olla suurempi kuin yhden siirron nopeus; sovelluksen samanaikaisuus määrää, kumpi tulos on merkityksellinen.
Voinko suorittaa kapasiteettitestin mitä tahansa julkista palvelinta vastaan?+
Käytä päätepisteitä, jotka hallitset tai joiden testaamiseen sinulla on lupa. Sovi kestosta, nopeudesta ja ajoituksesta, jotta mittaus ei häiritse muita palveluita.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- IETF RFC 6349: Kehys TCP-läpäisyn testaamiseen datatracker.ietf.org
- ESnet: iperf3:n kutsuminen software.es.net
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.