Justering av TCP/IP-prestanda för Azure VMs

Den här artikeln diskuterar vanliga tekniker för att justera TCP/IP-prestanda och några saker att överväga när du använder dem för virtuella maskiner som körs på Azure. Den ger en grundläggande översikt över teknikerna och utforskade hur virtuella datorer kan finjusteras.

Vanliga TCP/IP-inställningstekniker

MTU, fragmentering, och stort sändningsavlastning

MTU

Den maximala överföringsenheten (MTU) är den största storleksramen (paket plus nätverksåtkomsthuvuden) som anges i byte som kan skickas via ett nätverksgränssnitt. MTU är en konfigurerbar inställning. Standardinställningen för MTU som används på Azure VM och standardinställningen på de flesta nätverksenheter globalt är 1,500 byte.

Fragmentering

Fragmentering sker när ett paket skickas som överskrider MTU för ett nätverksgränssnitt. TCP/IP-stacken delar upp paketet i mindre delar (fragment) som överensstämmer med gränssnittets MTU. Fragmentering sker på IP-lagret och är oberoende av det underliggande protokollet (som TCP). När ett paket på 2 000 byte skickas via ett nätverksgränssnitt med en MTU på 1 500, delas paketet upp i ett paket på 1 500 byte och ett paket på 500 byte.

Nätverksenheter i vägen mellan en källa och en destination kan antingen släppa paket som överstiger MTU eller fragmentera paketet till mindre delar.

Biten "Inte fragmentera" i ett IP-paket

Don’t Fragment (DF)-biten är en flagga i IP-protokollhuvudet. DF-biten indikerar att nätverksenheter på vägen mellan avsändaren och mottagaren inte får fragmentera paketet. Denna bit kan sättas av många anledningar. (Se avsnittet "Path MTU Discovery" i den här artikeln för ett exempel.) När en nätverksenhet tar emot ett paket med bituppsättningen Don't Fragment och paketet överskrider enhetens MTU-gränssnitt är standardbeteendet att enheten släpper paketet. Enheten skickar ett ICMP-fragmenteringsmeddelande behövs tillbaka till paketets ursprungliga källa.

Prestandakonsekvenser av fragmentering

Fragmentering kan ha negativa prestandakonsekvenser. En av de främsta orsakerna till prestandaeffekten är processor-/minneseffekten av fragmenteringen och återmonteringen av paket. När en nätverksenhet behöver fragmentera ett paket måste den allokera PROCESSOR-/minnesresurser för att utföra fragmentering.

Samma sak händer när paketet sätts ihop igen. Nätverksenheten måste lagra alla fragment tills de tas emot så att den kan sätta ihop dem till det ursprungliga paketet.

Azure och fragmentering

Azure bearbetar inte fragmenterade paket med accelererat nätverk. När en VM tar emot ett fragmenterat paket bearbetar den icke-accelererade sökvägen det. Därför missar fragmenterade paket fördelarna med accelererat nätverk, till exempel lägre svarstid, minskad jitter och högre paket per sekund. Av denna anledning rekommenderar vi att undvika fragmentering om möjligt.

Azure släpper som standard fragmenterade paket som kommer till den virtuella datorn i fel ordning, vilket innebär att paketen inte matchar överföringssekvensen från källslutpunkten. Det här problemet kan uppstå när paket reser via Internet eller andra stora WAN-nätverk.

Justera MTU

Du kan förbättra det interna dataflödet för virtuellt nätverk genom att öka MTU:n för den virtuella datorns trafik. Men om den virtuella datorn kommunicerar med mål utanför det virtuella nätverket som har en annan MTU kan fragmentering inträffa och minska prestanda.

Mer information om hur du ställer in MTU på virtuella Azure-datorer finns i Konfigurera maximal överföringsenhet (MTU) för virtuella datorer i Azure.

Stor sändningslast

Stora sändningsavlastning (LSO) kan förbättra nätverksprestanda genom att avlasta segmenteringen av paket till ethernet-adaptern. När LSO är aktiverat skapar TCP/IP-stacken ett stort TCP-paket och skickar det till Ethernet-adaptern för segmentering innan det vidarebefordras. Fördelen med LSO frigör processorn från att segmentera paket i storlekar som överensstämmer med MTU och avlasta bearbetningen till ethernet-gränssnittets maskinvara. Mer information om fördelarna med LSO finns i Stöd för stor sändningslast.

När LSO är aktiverat kan Azure-kunder märka stora ramstorlekar under paketinsamlingar. Dessa stora ramstorlekar kan göra att vissa kunder antar att fragmentering sker eller att en stor MTU används när den inte är det. Med LSO kan Ethernet-adaptern annonsera en större maximal segmentstorlek (MSS) till TCP/IP-stacken för att skapa ett större TCP-paket. Ethernet-adaptern delar sedan upp hela den här icke-segmenterade ramen i många mindre ramar enligt dess MTU, som visas i en paketinsamling som utförs på den virtuella datorn.

TCP MSS fönsterskalning och PMTUD

TCP maximal segmentstorlek

TCP:s maximala segmentstorlek (MSS) är en inställning som begränsar storleken på TCP-segment, vilket undviker fragmentering av TCP-paket. Operativsystem använder vanligtvis den här formeln för att ange MSS:

MSS = MTU - (IP header size + TCP header size)

IP-huvudet och TCP-huvudet är 20 byte vardera, eller totalt 40 byte. Ett gränssnitt med en MTU på 1 500 har en MSS på 1 460. MSS kan konfigureras.

Denna inställning godkänns i TCP-trehandskakningen när en TCP-session upprättas mellan en källa och en destination. Båda sidorna skickar ett MSS-värde, och det lägre av de två används för TCP-anslutningen.

Tänk på att MTU:erna för källan och destinationen inte är de enda faktorerna som bestämmer MSS-värdet. Mellanliggande nätverksenheter, såsom VPN-gateways, inklusive Azure VPN-gateway, kan justera MTU oberoende av källan och destinationen för att säkerställa optimal nätverksprestanda.

Upptäckning av väg-MTU

MSS förhandlas, men det kanske inte indikerar den faktiska MSS som kan användas. Andra nätverksenheter i sökvägen mellan källan och målet kan ha ett lägre MTU-värde än källan och målet. I det här fallet släpper den enhet vars MTU är mindre än paketets storlek paketet. Enheten skickar tillbaka ett ICMP-fragmenteringsmeddelande (typ 3, kod 4) som innehåller dess MTU. Detta ICMP-meddelande tillåter källvärden att minska sin Path MTU på ett lämpligt sätt. Processen kallas Path MTU Discovery (PMTUD).

PMTUD-processen minskar nätverkets prestanda på grund av dess ineffektivitet. När MTU för en nätverksväg överskrids måste datapaket skickas om med en lägre MSS. Om en nätverksbrandvägg blockerar meddelandet ICMP Fragmentation Needed (ICMP-fragmentering krävs) förblir avsändaren omedveten om behovet av att sänka MSS och skickar om paketet upprepade gånger. Därför avråder vi från att öka MTU:n för virtuella Azure-datorer.

VPN och MTU

Om du använder virtuella datorer som utför inkapsling (till exempel virtuella IPsec-VPN:er) finns det några andra saker att tänka på när det gäller paketstorlek och MTU. VPN:er lägger till fler rubriker i paket. De tillagda rubrikerna ökar paketstorleken och kräver en mindre MSS.

Vi rekommenderar att du för Azure ställer in TCP MSS clamping till 1 350 byte och tunnelgränssnittets MTU till 1 400. Mer information finns på sidan VPN-enheter och IPsec/IKE-parametrar.

Latens, rundturstid och TCP window scaling

Latens och rundturstid

Ljusets hastighet avgör nätverksfördröjningen över ett fiberoptiskt nätverk. Resvägstiden (RTT) mellan två nätverksenheter styr TCP-nätverkets dataflöde.

Den här tabellen visar det räta avståndet mellan två platser. I nätverk är avståndet vanligtvis längre än det raka avståndet. Här är en enkel formel för att beräkna minsta RTT som styrs av ljusets hastighet:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Du kan använda 200 för spridningshastigheten. Utbredningshastigheten är avståndet i kilometer som ljuset färdas på 1 millisekund.

Låt oss ta New York till San Francisco som ett exempel. Det raka avståndet är 4 148 km. Om du anger det värdet i ekvationen resulterar det i följande ekvation:

Minimum RTT = 2 * (4,148 / 200)

Resultatet av ekvationen är i millisekunder.

Om du vill få bästa nätverksprestanda är det logiska alternativet att välja mål med det kortaste avståndet mellan dem. Du bör också utforma ditt virtuella nätverk för att optimera trafikens väg och minska latensen. För mer information, se avsnittet "Överväganden för nätverksdesign" i den här artikeln.

Latens och effekter av rundtripptid på TCP

Restid (round-trip time) har en direkt effekt på maximal TCP-genomströmning. I TCP-protokollet är fönsterstorleken den maximala mängden trafik som kan skickas via en TCP-anslutning innan avsändaren behöver ta emot bekräftelse från mottagaren. Om TCP MSS är inställt på 1 460 och TCP-fönsterstorleken är inställd på 65 535, kan avsändaren skicka 45 paket innan bekräftelse från mottagaren. Om avsändaren inte får bekräftelse överför den data igen. Här är formeln:

TCP window size / TCP MSS = packets sent

I det här exemplet, avrundas 65,535 / 1,460 upp till 45.

Det här tillståndet "väntar på bekräftelse", en mekanism för att säkerställa tillförlitlig dataleverans, är det som gör att RTT påverkar TCP-dataflödet. Ju längre avsändaren väntar på bekräftelse, desto längre tid behöver den vänta innan mer data skickas.

Här är formeln för att beräkna maximal genomströmning för en enskild TCP-anslutning:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Den här tabellen visar den maximala genomströmningen i megabyte per sekund för en enda TCP-anslutning. (För läsbarhet används megabyte som måttenhet.)

Om paket går förlorade minskas det maximala dataflödet för en TCP-anslutning medan avsändaren överför data som skickas på nytt.

TCP-fönsterskalning

TCP-fönsterskalning är en teknik som dynamiskt ökar TCP-fönsterstorleken så att mer data kan skickas innan en bekräftelse krävs. I föregående exempel skulle 45 paket skickas innan en bekräftelse krävdes. Om du ökar antalet paket som kan skickas innan en bekräftelse behövs minskar du antalet gånger som en avsändare väntar på bekräftelse.

Den här tabellen illustrerar dessa relationer.

TCP-headerns värde för TCP-fönsterstorleken är bara 2 byte långt, vilket betyder att det maximala värdet för ett mottagningsfönster är 65 535. För att öka den maximala fönsterstorleken infördes en TCP-fönsterskalningsfaktor.

Skalfaktorn är också en inställning som du kan konfigurera i ett operativsystem. Här är formeln för att beräkna TCP-fönsterstorleken med hjälp av skalningsfaktorer:

TCP window size = TCP window size in bytes * (2^scale factor)

Här är beräkningen för en fönsterskalningsfaktor på 3 och en fönsterstorlek på 65,535.

65,535 * (2^3) = 524,280 bytes

En skalningsfaktor på 14 resulterar i en TCP-fönsterstorlek på 14 (det maximala förskjutning som tillåts). TCP-fönsterstorleken är 1 073 725 440 byte (8,5 gigabit).

Stöd för TCP-fönsterskalning

Windows kan ställa in olika skalningsfaktorer för olika anslutningstyper. (Klasser av anslutningar inkluderar datacenter, Internet och så vidare.) Du använder Get-NetTCPConnection PowerShell-kommandot för att visa anslutningstypen för fönsterskalning:

Get-NetTCPConnection

Du kan använda PowerShell-kommandot Get-NetTCPSetting för att visa värdena för varje klass:

Get-NetTCPSetting

Du kan ange den inledande TCP-fönsterstorleken och TCP-skalningsfaktorn i Windows med hjälp Set-NetTCPSetting av PowerShell-kommandot. Mer information finns i Set-NetTCPSetting.

Set-NetTCPSetting

Följande värden är de effektiva TCP-inställningarna för AutoTuningLevel:

Dessa inställningar är de som troligast påverkar TCP-prestanda, men kom ihåg att många andra faktorer på internet, utanför Azures kontroll, också kan påverka TCP-prestanda.

Accelererad nätverks- och mottagarskalning

Accelererad nätverkshantering

Nätverksfunktioner för virtuella datorer är historiskt processorintensiva på både den virtuella gästdatorn och hypervisor-värden. Värd-CPU:n behandlar i programvara alla paket som passerar genom värden, inklusive all virtuell nätverksinkapsling och avinkapsling. Ju mer trafik som går genom värdmaskinen, desto högre CPU-belastning. Om värdprocessorn är upptagen med andra åtgärder som påverkar nätverkets dataflöde och svarstid. Azure löser detta problem med accelererat nätverk.

Accelererad nätverksanslutning ger konsekvent ultralåg nätverkslatens genom Azures interna programmerbara hårdvara och teknologier som SR-IOV. Accelererad nätverkshantering flyttar mycket av Azure's programvarudefinierade nätverksstack från CPU:erna till FPGA-baserade SmartNICs. Den här ändringen gör det möjligt för slutanvändarprogram att återta beräkningscykler som lägger mindre belastning på den virtuella datorn, vilket minskar jitter och inkonsekvens i svarstiden. Med andra ord kan prestanda vara mer deterministisk.

Accelererad nätverkskoppling förbättrar prestandan genom att låta gäst-VM:et kringgå värden och upprätta en datapath direkt med en värds SmartNIC. Här är några fördelar med accelererat nätverk:

• Lägre svarstid/högre paket per sekund (pps): Om du tar bort den virtuella växeln från datanätvägen eliminerar du den tid som paketen spenderar i värddatorn för policybearbetning och ökar antalet paket som kan bearbetas i den virtuella maskinen.

• Minskad jitter: Bearbetning av virtuella växlar beror på hur mycket princip som måste tillämpas och arbetsbelastningen för processorn som utför bearbetningen. Genom att överföra policyimplementeringen till hårdvaran elimineras den variabiliteten genom att leverera paket direkt till den virtuella maskinen, vilket eliminerar kommunikation mellan värd och virtuell maskin samt alla programvaruavbrott och kontextväxlingar.

• Minskad CPU-användning: Om du kringgår den virtuella växeln i värden leder det till mindre processoranvändning för bearbetning av nätverkstrafik.

För att använda accelererat nätverk måste du uttryckligen aktivera det på varje tillämplig virtuell dator. Anvisningar finns i Skapa en virtuell Linux-dator med accelererat nätverk .

Inkommande sidans skalning

Tekniken Receive Side Scaling (RSS) är en nätverksdrivrutinteknologi som effektivt fördelar mottagandet av nätverkstrafik genom att fördela mottagningsprocessen över flera CPU:er i ett multiprocessorsystem. Enkelt uttryckt tillåter RSS ett system att hantera mer mottagen trafik eftersom det använder alla tillgängliga processorer istället för bara en. För en mer teknisk diskussion om RSS, se Introduktion till mottagarsideskalning.

För att få bästa prestanda när accelererat nätverk är aktiverat på en VM, behöver du aktivera RSS. RSS kan även ge fördelar på virtuella maskiner som inte använder accelererad nätverkning. En översikt över hur du avgör om RSS är aktiverat och hur du aktiverar det finns i Optimera nätverksdataflöde för virtuella Azure-datorer.

TCP TIME_WAIT och TIME_WAIT-bortskaffande

TCP-TIME_WAIT är en annan vanlig inställning som påverkar nätverks- och programprestanda. Upptagna virtuella datorer öppnar och stänger ofta många socketar, antingen som klienter eller servrar. Under normala TCP-åtgärder går en socket ofta in i TIME_WAIT tillstånd och finns kvar där under en längre period. Detta tillstånd säkerställer att kvarvarande data levereras genom socketen innan den stängs. Därför förhindrar TCP/IP-stackar vanligtvis socket återanvändning genom att släppa klientens TCP SYN-paket tyst.

Du kan konfigurera hur länge en socket förblir i TIME_WAIT tillstånd. Varaktigheten kan variera från 30 sekunder till 240 sekunder. Sockets är en begränsad resurs och deras tillgänglighet kan konfigureras. Normalt är cirka 30 000 sockets tillgängliga för användning vid en viss tidpunkt. Om systemet använder alla tillgängliga socketar eller om klienter och servrar använder felmatchade TIME_WAIT inställningar kan den virtuella datorn försöka återanvända en socket som fortfarande är i TIME_WAIT tillstånd. I sådana fall misslyckas nya anslutningar eftersom TCP SYN-paketen tas bort tyst.

Värdet för portintervallet för utgående socketar kan konfigureras i TCP/IP-stacken för ett operativsystem. Samma sak gäller för TCP TIME_WAIT-inställningar och återanvändning av socket. Att ändra dessa siffror kan potentiellt förbättra skalbarheten. Men beroende på situationen kan dessa förändringar orsaka interoperabilitetsproblem. Du bör vara försiktig om du ändrar dessa värden.

Du kan använda TIME_WAIT-"assassination" för att hantera denna skalningsbegränsning. TIME_WAIT-avlivning tillåter att en socket återanvänds i vissa situationer, som när sekvensnumret i IP-paketet för den nya anslutningen överstiger sekvensnumret i det sista paketet från den tidigare anslutningen. I det här fallet tillåter operativsystemet att den nya anslutningen upprättas (den accepterar den nya SYN/ACK) och tvingar den tidigare anslutningen som var i ett TIME_WAIT tillstånd att stängas. Denna kapacitet stöds på Windows virtuella maskiner i Azure. För att få information om stöd i andra virtuella maskiner, kontakta operativsystemets leverantör.

Mer information om hur du konfigurerar TCP-TIME_WAIT inställningar och källportintervall finns i Inställningar som kan ändras för att förbättra nätverksprestanda.

Faktorer för virtuella nätverk som kan påverka prestanda

Maximal utgående bandbredd för virtuella maskiner

Azure har olika storlekar och typer av virtuella datorer, var och en med olika typer av prestandafunktioner. En av dessa förmågor är nätverksthroughput (eller bandbredd), som mäts i megabit per sekund (Mbps). Eftersom virtuella maskiner är placerade på delad hårdvara måste nätverkskapaciteten delas rättvist bland de virtuella maskinerna som använder samma hårdvara. Större virtuella maskiner tilldelas mer bandbredd än mindre virtuella maskiner.

Nätverksbandbredden som allokeras till varje virtuell dator mäts på utgående trafik (utgående) från den virtuella datorn. All nätverkstrafik som lämnar den virtuella maskinen räknas mot den tilldelade gränsen, oavsett destination. Om en virtuell dator har en gräns på 1 000 Mbit/s gäller den gränsen om den utgående trafiken är avsedd för en annan virtuell dator i samma virtuella nätverk eller utanför Azure.

Ingress mäts inte eller begränsas direkt. Men det finns andra faktorer, såsom begränsningar i CPU och lagring, som kan påverka en virtuell maskins förmåga att behandla inkommande data.

Accelererad nätverksfunktionalitet är utformad för att förbättra nätverksprestanda, inklusive latens, genomströmning och CPU-användning. Accelererad nätverksanslutning kan förbättra en virtuell maskins genomströmning, men det kan den bara göra upp till den tilldelade bandbredden för den virtuella maskinen.

Virtuella Azure-datorer har minst ett nätverksgränssnitt kopplat till sig. De kan ha flera. Bandbredden som tilldelas en virtuell maskin är summan av all utgående trafik över alla nätverksgränssnitt som är anslutna till maskinen. Med andra ord tilldelas bandbredden baserat på varje virtuell maskin, oavsett hur många nätverksgränssnitt som är anslutna till maskinen.

Förväntat utgående dataflöde och antalet nätverksgränssnitt som stöds av varje VM-storlek beskrivs i Storlekar för virtuella Windows-datorer i Azure. Om du vill se maximalt dataflöde väljer du en typ, till exempel Generell användning, och hittar sedan avsnittet om storleksserien på den resulterande sidan (till exempel "Dv2-serien"). För varje serie finns det en tabell som ger nätverksspecifikationer i den sista kolumnen, som har titeln "Max NIC:ar / Förväntad nätverksbandbredd (Mbps)."

Genomströmningsbegränsningen gäller för den virtuella maskinen. Dataflödet påverkas inte av följande faktorer:

• Antal nätverksgränssnitt: Bandbreddsgränsen gäller för summan av all utgående trafik från den virtuella datorn.

• Accelererat nätverk: Även om den här funktionen kan vara till hjälp för att uppnå den publicerade gränsen ändrar den inte gränsen.

• Trafikmål: Alla mål räknas mot gränsen för utgående trafik.

• Protokoll: All utgående trafik över alla protokoll räknas mot gränsen.

Mer information finns i Nätverksbandbredd för virtuella datorer.

Optimering av virtuella Linux-datorer

Moderna Linux-kärnor har funktioner som kan hjälpa till att uppnå konsekvens och prestanda, som ibland krävs för vissa arbetsbelastningar.

Mer information finns i Optimera nätverksbandbredd på virtuella Azure-datorer

Internetprestandaöverväganden

Som diskuterats genom hela denna artikel, faktorer på internet och utanför Azures kontroll kan påverka nätverkets prestanda. Här är några av dessa faktorer:

• Svarstid: Tur och retur-tiden mellan två slutpunkter påverkas av problem i mellanliggande nätverk, av trafik som inte tar den "kortaste" avståndsvägen och av suboptimala peeringsökvägar.

• Paketförlust: Paketförlust orsakas av överbelastning i nätverket, problem med fysiska sökvägar och underpresterande nätverksenheter.

• MTU-storlek/fragmentering: Fragmentering längs sökvägen kan leda till fördröjningar i data ankomst eller i paket som anländer i fel ordning, vilket kan påverka leveransen av paket.

Traceroute är ett bra verktyg för att mäta nätverksprestandaegenskaper (som paketförlust och latens) längs varje nätverksväg mellan en källenhet och en destinationenhet.

Överväganden för nätverksdesign

Tillsammans med de överväganden som diskuterats tidigare i denna artikel kan topologin hos ett virtuellt nätverk påverka nätverkets prestanda. Till exempel kan en hub-and-spoke-design som överför trafik tillbaka globalt till ett virtuellt nätverk med en enda hubb introducera fördröjning i nätverket, vilket påverkar den övergripande prestandan hos nätverket.

Antalet nätverksenheter som nätverkstrafiken passerar genom kan också påverka den totala latensen. Om trafiken passerar via en virtuell ekernätverksinstallation och en virtuell hubbinstallation innan den överförs till Internet i en nav-och-eker-design medför de virtuella nätverksinstallationerna viss svarstid.

Azure-regioner, virtuella nätverk och latens

Azure-regioner består av flera datacenter som finns inom ett allmänt geografiskt område. Dessa datacenter kanske inte ligger fysiskt bredvid varandra. I vissa fall avgränsas de med så mycket som 10 kilometer. Det virtuella nätverket är ett logiskt överlagringslager ovanpå Azures fysiska datacenternätverk. Ett virtuellt nätverk antyder ingen specifik nätverkstopologi inom datacentret.

Till exempel kan två virtuella datorer som är i samma virtuella nätverk och undernät vara i olika rack, rader eller till och med datacenter. De kan separeras med meter eller kilometer av fiberoptisk kabel. Denna variation kan introducera varierande latens (några millisekunders skillnad) mellan olika virtuella maskiner.

Den geografiska placeringen av virtuella datorer och den potentiella svarstiden mellan två virtuella datorer påverkas av konfigurationen av tillgänglighetsuppsättningar, närhetsplaceringsgrupper och tillgänglighetszoner. Men avståndet mellan datacenter i en region är region-specifikt och påverkas främst av datacenter-topologin i regionen.

Uttömning av Source NAT-portar

En distribution i Azure kan kommunicera med slutpunkter utanför Azure på det offentliga internet och/eller i det offentliga IP-utrymmet. När en instans initierar en utgående anslutning, mappar Azure dynamiskt den privata IP-adressen till en offentlig IP-adress. Efter att Azure har skapat denna mappning, kan returtrafik för det utgående flödet också nå den privata IP-adressen där flödet ursprungligen kom ifrån.

För varje utgående anslutning måste Azure Load Balancer upprätthålla denna mappning under en viss tidsperiod. Med Azures flertenantarkitektur kan det vara resurskrävande att upprätthålla denna mappning för varje utgående flöde för varje virtuell maskin. Så det finns gränser som är fastställda och baserade på konfigurationen av Azure Virtual Network. Eller, för att säga att mer exakt, en virtuell Azure-dator bara kan göra vissa utgående anslutningar vid en viss tidpunkt. När dessa gränser har nåtts skapar den virtuella datorn inte fler utgående anslutningar.

Men det här beteendet kan konfigureras. Mer information om SNAT- och SNAT-portöverbelastning finns i den här artikeln.

Mät nätverksprestanda på Azure

Många av de maximala prestandavärdena i den här artikeln är relaterade till nätverksfördröjningen/tidsåtgången (RTT) mellan två virtuella datorer. Detta avsnitt ger några förslag på hur man testar latens/RTT, hur man testar TCP-prestanda och prestanda i VM-nätverk. Du kan justera och prestandatesta de TCP/IP- och nätverksvärden som diskuterades tidigare genom att använda de tekniker som beskrivs i det här avsnittet. Ange värden för svarstid, MTU, MSS och fönsterstorlek i beräkningarna som angavs tidigare och jämför teoretiska maxvärden med faktiska värden som observerades under testningen.

Mät fram- och återresan tid och paketförlust

TCP-prestanda beror starkt på RTT och paketförlust. Ping-verktyget som är tillgängligt i Windows och Linux ger det enklaste sättet att mäta RTT och paketförlust. Utdata från PING visar svarstiden minimum/maximum/average mellan en källa och ett mål. Den visar paketförlust. PING använder som standard ICMP-protokollet. Du kan använda PsPing för att testa TCP RTT. Mer information finns i PsPing.

ICMP- och TCP-pingar mäter inte den accelererade nätverksdatasökvägen. Om du vill mäta datasökvägen läser du om Latte och SockPerf i den här artikeln.

Mäta den faktiska bandbredden för en virtuell dator

Följ den här vägledningen om du vill mäta bandbredden för virtuella Azure-datorer korrekt.

Mer information om hur du testar andra scenarier finns i följande artiklar:

• Felsökning av ExpressRoute-nätverksprestanda

• Så här validerar du VPN-dataflöde till ett virtuellt nätverk

Identifiera ineffektiva TCP-beteenden

I paketinsamlingar kan Azure-kunder se TCP-paket med TCP-flaggor (SACK, DUP ACK, RETRANSMIT och FAST RETRANSMIT) som kan tyda på problem med nätverksprestanda. Dessa paket specifikt indikerar nätverksineffektivitet som uppstår från paketförlust. Paketförlust orsakas inte nödvändigtvis av prestandaproblem i Azure. Prestandaproblem kan bero på applikationer, operativsystem eller andra problem som kanske inte är direkt relaterade till Azure-plattformen.

Kom också ihåg att vissa återutsändningar och dubblett-ACK:ar är normala i ett nätverk. TCP-protokoll skapades för att vara tillförlitliga. Förekomsten av dessa TCP-paket i en paketfångst indikerar inte nödvändigtvis ett systemiskt nätverksproblem, såvida de inte är överdrivna.

Ändå är dessa pakettyper indikationer på att TCP-genomströmningen inte uppnår sin maximala prestanda, av skäl som diskuteras i andra avsnitt av denna artikel.

Nästa steg

Nu när du har lärt dig mer om TCP/IP-prestandajustering för virtuella Azure-datorer kan du utforska andra faktorer för att planera virtuella nätverk. Du kan också lära dig mer om att ansluta och konfigurera virtuella nätverk.