TCP/IP-specifikus problémák
Számos programozási technika teljesítményproblémákba futhat, amelyek a TCP/IP megvalósításhoz kötődnek.
A teljesítménybeli problémákból nem gondolnánk, hogy a TCP/IP kevésbé hatékony, vagy egy szűk keresztmetszet okoz gondot, holott ezek a problémák akkor láthatók, amikor a TCP/IP műveletek nem közismertek.
A következő problémák egy általános környezetet mutatnak be, amelyben a TCP/IP műveletek és a hálózati alkalmazásfejlesztés döntései gyenge teljesítményt eredményeznek.
- Erős-kapcsolatú alkalmazások.
Némely alkalmazás minden tranzakcióhoz egy új TCP kapcsolatot nyit. A TCP kapcsolat felépítése időigényes, az adatcsomag-visszaérkezési idő, és a kapcsolat kezdete lassú. Ezen kívül a lezárt kapcsolat TIME-WAIT állapotba kerül, amely rendszererőforrást emészt fel.
Ilyen alkalmazások általánosak, mivel könnyű létrehozni, tesztelni, és a hibát kezelni is könnyű. Hibát észlelni egy fennmaradó kapcsolaton komolyabb kódot és erőfeszítést igényel, ami néha nem valósul meg.
Erre a szituációra megoldás a TCP kapcsolat újrafelhasználása. Ez folytatólagos használatot jelent a TCP kapcsolat felett, amíg a tranzakció fel nem bomlik több kapcsolatra. Ha ezt a fejlesztést elértük, akkor a kapcsolatok számát kettőre korlátozhatjuk és az alkalmazásréteg keretezése, valamint fejlett hibakezelés szükséges.
- Zéró-hosszúságú puffer-küldés és küldés blokkolás.
A pufferelés kikapcsolása a setsockopt függvénnyel (SO_SNDBUF) 0-ra hasonló, mintha kikapcsolnánk a lemez-gyorsítótárat. Amikor 0-ra állítjuk a küldési puffert, akkor az alkalmazásnak 50% esélye van, hogy eltalálja a 200 ezredmásodperces késleltetett visszaigazolást.
Ne kapcsoljuk ki a küldési puffert, hacsak úgy nem döntöttünk, hogy valamennyi hálózati környezeti változót kikapcsoljuk. Egy kivétel: az adatfolyam-adat átlapolt I/O-t használ, a küldési puffer 0-ra állításához.
- Küldés – küldés-fogadás programozási modell.
Egy alkalmazás strukturálása, hogy küldés – küldés-fogadás műveleteket végezzen, növeli az esélyét, hogy összetalálkozzunk a Nagle Algoritmussal, amely egy RTT (oda-vissza út ideje) +200ms késleltetést okoz. A Nagle Algoritmussal akkor találkozhatunk, ha az utolsó küldés kisebb, mint a TCP maximum szegmensméret (MSS a maximális adat egy egyedi datagram-ban). Az MSS nagyon nagy érték lehet (64K IPv4-ben, és még nagyobb IPv6-ban), így ne számoljunk egy tipikusan kisméretű MSS-t. A legjobb választás, ha kombináljuk a két küldést egy egyedi küldésbe a WSASend vagy memcpy függvényeket felhasználva.
- Nagyszámú szimultán kapcsolatok.
Konkurens kapcsolatok nem érhetik el a kettőt, kivéve speciális igényű alkalmazásoknál. A két konkurens kapcsolat túllépése erőforrás-pazarlást eredményez. Egy jó szabály, hogy legyen négy rövid életű kapcsolatunk, vagy két fennmaradó kapcsolatunk célgépenként.
Lassú alkalmazások felismerése
Most azonosítunk egy lassú alkalmazást, mint egy Microsoft Windows alkalmazást, lecsökkent teljesítménnyel. Egy lassú alkalmazás az alábbi tünetek közül egyet vagy többet mutat be:
- A CPU és a hálózati kihasználtság alacsony. Úgy tűnik, hogy a gép vár valamire. Gyakran az alkalmazás vár a hálózatra.
- A Nagle Algoritmus kikapcsolása a TCP_NODELAY socket opción keresztül növelheti a teljesítményt. Ez más problémákat jelezhet, és nem lehet végleges megoldás. A Nagle algoritmus kikapcsolása növeli a protokoll költséget. Ne használjuk ezt a módszert fix megoldásként összeomlott alkalmazásoknál – csak egy jelzésnek, hogy az alkalmazásnak szüksége van pluszmunkára, hogy megoldja a teljesítmény problémáit.
- Az alkalmazás magas feldolgozási költséget mutat. Ahhoz, hogy kiszámoljuk az alkalmazásunk futási költségét, határozzuk meg, hogy mennyi adatot szándékozunk átküldeni egy alkalommal. Ezután használjuk a Netstat-ot és adjunk (Ethernet-hez) 60 byte-ot minden csomaghoz és 500 byte-ot minden kapcsolathoz. A legnagyobb felső érték, amely remélhető az Ethernet feletti átvitelben körülbelül 6%. Modemes kapcsolatnál ez 2%, miáltal a PPP kapcsolat fejléctömörítést használ.
- Az alkalmazás válasza lelassul, amikor a kapcsolatnak magas körforgási ideje (RTT) van. Feltételezve, hogy az alkalmazás nem közelíti meg a kapcsolat sávszélességét, egy magas RTT-nek kevés vagy semmilyen hatása nincs. Egy drámai lassulás magas RTT-vel tisztán mutatja a folytatásos feldolgozást és a sok apró tranzakciót.
Minden alkalmazást tesztelni kellene magas RTT-jű környezetben. Kijelenthetjük, hogy a legtöbb alkalmazás a hibás döntések miatt olyan amilyen. Ez a tesztelés sok mindenre fényt deríthet, ha számos környezetben próbálkozunk, mint pl. vezeték nélküli LAN, kapcsolat késleltetés szimulátor.
Többletmunka számítása a Netstat-al
A Netstat segítségével megvalósított többletmunka-számítás csendes hálózaton alkalmazható.
- Kérdezzük le az aktuális interfész statisztikát a Netstat segítségével.
- Futtassuk az alkalmazást.
- Kérdezzük le újra az interfész statisztikát, újra a Netstat-ot használva.
- Számítsuk ki a fogadott bájtokat a két Netstat mérték között.
Az alábbi példa illusztrálja ezeket a lépéseket TTCP-t használva, hogy 10 bájtot küldjünk, egy bájtot egyszerre.
Először egy elméleti többletmunkát számítunk az alkalmazáshoz. Ehhez a teszthez minden csomag 60 bájtos (Az Ethernet minimum). Ez az átvitel három csomagot igényel, hogy beállítsuk a kapcsolatot, 10 adatcsomagot, 10 visszaigazoló csomagot (a késleltetett visszaigazolás minden pillanatban közeli), és négy csomagot a kapcsolat lezárásához.
Ez megfelel 27 db 60 bájtos csomagnak, vagy 1620 bájtnak (3+4+10+10)*60=1620). Amióta csak 10 bájtot küldünk át, a kihasználtság 1610 bájt, amely 99% protokoll-kihasználtságot jelent.
A mellékletben megtalálhatók a parancsok és a statisztikák.
Számítások
Küldött: 816 bájt
Fogadott: 674 bájt
Összes bájt: 1490
Felhasználói ebből: 10
Plusz költség: 1480/1490 = 99.3%
5 bájt/másodperc (vagy 40 bit/s)