Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Vissa programmeringstekniker stöter på prestandaproblem som är kopplade till implementeringen av TCP/IP. Sådana prestandaproblem tyder inte på att TCP/IP är ineffektivt eller en flaskhals för prestanda. I stället visas dessa problem när TCP/IP-åtgärder inte förstås.
Följande problem identifierar vanliga scenarier där kombinationen av TCP/IP-åtgärd och val av nätverksprogramutveckling resulterar i dåliga prestanda.
Anslutningsintensiva program.
Vissa program instansierar en ny TCP-anslutning för varje transaktion. TCP-anslutningsetablering tar tid, bidrar med extra RTT och är föremål för långsam start. Dessutom är de stängda anslutningarna föremål för TIME-WAIT, som förbrukar systemresurser.
Anslutningsintensiva program är vanliga till stor del eftersom de är enkla att skapa. testning och felhantering är mycket enkel. Det kan ta lång tid att identifiera fel på en beständig anslutning och det kan ta lång tid att utföra kod och arbete och därför ibland inte slutföras.
Åtgärda den här situationen genom att återanvända TCP-anslutningen. Detta kan orsaka serialisering över TCP-anslutningen om inte transaktionerna multiplexeras över flera anslutningar. Om den här metoden används bör antalet anslutningar begränsas till två, och inramning på programnivå och avancerad felhantering krävs.
Skicka buffertar med noll längd och blockerande skickar.
Att stänga av buffring med hjälp av funktionen setsockopt för att ställa in sändningsbufferten (SO_SNDBUF) på noll liknar att stänga av diskcachelagring. När du ställer in sändningsbufferten till noll och skickar blockeringsmeddelanden har ett program 50 procents chans att nå en fördröjd bekräftelse på 200 millisekunder.
Inaktivera inte sändningsbuffertning om du inte har beaktat effekten i alla nätverksmiljöer. Ett undantag: strömmande data med överlappande I/O bör ange sändningsbufferten till noll.
Send-Send-Receive programmeringsmodell.
Att strukturera ett program för att utföra send-send-receives ökar dina chanser att stöta på Nagle-algoritmen, vilket orsakar en fördröjning på RTT +200 ms. Nagle-algoritmen kan påträffas om den senaste sändningen är mindre än TCP Maximum Segment Size (MSS, maxdata i ett enda datagram). MSS kan vara ett mycket stort värde (64K i IPv4 och ännu större i IPv6), så räkna inte med en vanligtvis liten MSS. Ett bättre alternativ är att kombinera de två skickar till en enda skicka med hjälp av WSASend eller memcpy funktion.
Stort antal samtidiga anslutningar.
Samtidiga anslutningar får inte överskrida två, förutom i särskilda program. Om två samtidiga anslutningar överskrids resulterar det i bortkastade resurser. En bra regel är att ha upp till fyra kortlivade anslutningar eller två beständiga anslutningar per mål.
Relaterade ämnen