Statískt IP í GCP á móti VPN-hraða: þrjár breytur, eitt próf

Flutningurinn varð hraðari eftir að vistfangið var frátekið, og niðurstan skrifaði sig sjálf. Nema að sama breytingin skipti líka göngunum úr UDP á TCP, færði prófið á aðra kvöldstund og lenti kannski á VM í öðru svæði. Að taka frá ytra vistfang lagar lífsferilsvandamál: það heldur endapunktinum sama milli endurræsinga. Það hefur engan búnað sem myndi flýta fyrir pökkum, svo hraðamunurinn í þeirri tilraun tilheyrir hinum breytunum, og ákvörðunin sem liggur fyrir þér er hver á að prófa næst.

Hvað frátekið vistfang kaupir í raun

Compute Engine greinir á milli skammvinnra vistfanga, sem úthlutað er og sleppt með tilvikinu, og statískra vistfanga sem þú tekur frá og heldur. Sá munur snýst um varðveislu og reikningagerð, ekki slóðina sem pakki fer. Stöðugur endapunktur er sannarlega gagnlegur fyrir DNS-færslur, snið fyrir fjartengingu, heimildalistasamstarfsaðila og eldveggjarreglur sem eiga ekki að breytast þegar VM er endurræst.

Þetta eru góðar ástæður til að taka eitt frá. Engin þeirra er afkastaástæða.

Haltu lagi, vistfangi og flutningi sem þremur breytum

Google Cloud selur líka Premium og Standard Network Service Tiers og bæði fara ólíkar leiðir á internetið með mismunandi aðgengi að eiginleikum. Statísk vistfangsstilling er hornrétt á bæði, svo meðhöndlaðu statískt og Premium sem ótengdar staðreyndir um VM en ekki samheiti. Skráðu raunverulegt lag, svæðið og hvers kyns samtengingu eða viðhengj sem er í gangi, því þau lýsa slóðinni á þann hátt sem vistfangsmerkimiðinn mun aldrei gera.

Þrjár breytur, þrjár aðskildar tilraunir, annars er niðurstan saga en ekki mæling.

Hannaðu próf sem svarar einni spurningu

Haltu VM, vistfangi, staðsetningu biðlarans, áfangastað og álagi föstum á meðan þú ber saman samþykkt UDP og TCP snið. Þarf er bæði þjónarhlustara fyrir hvern flutning og samsvarandi eldveggjarreglur; að breyta leitarorði í biðlaranum og skilja hlustarann óbreyttan prófar ekkert nema þolinmæði þína. Notaðu endurtekinn flutning og skráðu stefnu, tímalengd, stakar á móti samhliða streymur og einingarnar, því MB/s og Mb/s eru átta sinnum ólík.

Fylgstu líka með örgjörva VM, því lítið tilvik mettast á dulritun eða softirq-vinnu löngu áður en netið gerir það, og það þak mun líta nákvæmlega út eins og takmörk þjónustuveitanda.

Endursendingar- og tapsmælar frá VM og biðlara aðskilja slóðarvandamál frá flutningsvandamáli, og framvindustika getur það ekki. Vinnanleg röð með iperf3 tekur um það bil tíu mínútur á hvern flutning. Ræstu þjóninn hinum megin, keyrðu biðlarann í þrjátíu sekúndur í hvora átt og endurtaktu hvora átt þrisvar. Heftu fyrstu keyrslu hverrar röðar og berðu svo saman hraða sendanda og móttakanda ásamt endursendingartölunni sem TCP-keyrslurnar prenta.

Hvers vegna UDP og TCP eru vélrænt ólík

OpenVPN yfir UDP ber gagnagramma og lætur eigin flutning forritsins sjá um tap. Yfir TCP liggur áreiðanleg straumur gangsins undir þegar áreiðanlegum forritsstraumi, svo eitt týnt hluti stöðvar allt sem á eftir kemur á meðan ytri tengingin endursendir samkvæmt eigin áætlun. Þessi hegðun fremst í röðinni er eiginleiki þess að gönguleggja TCP inni í TCP, ekki stefna þjónustuveitanda. Meðferð MTU og MSS er líka ólík milli aðferðanna tveggja, sem breytir sundrunarhegðun á sömu slóð.

Hraðara TCP-próf sannar því að TCP var hraðara þann dag á þeirri slóð, og ekkert almennara.

Skrifaðu niðurstöðuna þannig að hún standist yfirferð

Varnarhæf niðurstaða hefur form: þetta snið, á þessari vélarstærð, á þessu netlagi, hélt þessu mælda álagi í þessa átt við þessar aðstæður. Eitthvað víðtækara þarf fleiri keyrslur en eitt kvöld getur veitt. Ef hægara tilfellið stendur óútskýrt skaltu halda því sem athugun með sönnunargögnum sínum um pakka og auðlindir í stað þess að finna upp takmörkun sem ekkert skjal þjónustuveitanda lýsir.

Stöðugleiki vistfangs og flutningshraði geta bæði skipt máli fyrir sömu uppsetningu, og gagnleg ákvörðun er hvoru tveggja þú kaupir með hverri breytingu.