A hálózati forgalomban sok-sok szereplő vesz részt, két végpont (a számítógéped és a távoli szerver) között számtalan kis kütyü, elosztó, satöbbi van. Ha elkezdesz forgalmazni, akkor ezek a kis (és néha igen nagy) bigyók tárolják az első elküldött bájtokat az átmeneti tárukban, ennek a feltöltése pedig gyors, így a feltöltésed kezdete "megszalad".

Utána az átmeneti tárak olyan gyorsan ürülnek és töltődnek az általad küldött további bájtokkal, amilyen gyorsan a sorban következő eszköz fogadni tudja őket. Itt lassul be tehát a dolog?

Ez elméletileg jól hangzik, azonba a gyakorlat az, hogy a forgalomban részt vevő hálózati eszközök nagy részének nem olyan nagy az átmeneti táruk, hogy  a fenti mémet okozzák. Valójában leginkább a cső másik végén lévő szerverszoftver a ludas.

Ott is van átmeneti tár, amit az operációs rendszer kezel és minden egyes kapcsolathoz létrehoz egyet. Például ha elkezdesz forgalmazni egy Apple gép felé, akkor az azon lévő OSX létrehoz a kapcsolatodhoz egy 256 kbyte méretűt, ami pillanatok alatt megtelik. Az OSX erről a helyről táplál mondjuk egy Apache + PHP kombót, ami meg feldolgozza az adatokat, például folyamatosan fájlba írja, ha ez egy fájlfeltöltés.

A bibi itt van, az operációs rendszer (általában, jó beállítás esetén) piszok gyorsan kezeli az átmeneti tárat, tehát nagyon gyorsan tudná fogadni az adatokat, de az azon futó (szerver)szoftver már általában lassabb. Sok feltöltés tehát nem a hálózati sebesség, hanem a fogadó eszköz terheltsége és az azon lévő fogadó szoftver sajátosságából adódóan lassabb.

A fentieknek mekkora a hatása? Készítettem iPhone-ra egy kis webszervert, mert szükség volt fájlfeltöltésre WiFi-n keresztül a készülő programomhoz. Van erre Cocoa mintakód, de hiába optimalizáltam, nem tudtam 150 kbyte/s fölé menni, pedig SCP-n keresztül 900 kbyte/s-al is működik a dolog.

Tovább próbálkoztam hát és kiderült, hogy a buta Cocoa 510 bájtonként adta át az adatokat a programomnak és ezért marha sok fordulóra volt szükség egy nagyobb fájl fogadásához. Egy (nem Cocoa-s) trükkel megoldottam, hogy fordulónként akár 65 535 bájt is jöhessen, ami 150 helyett 1000 kbyte/s feltöltési sebességet eredményezett és drasztikusan csökkent a CPU használat is.

Software is teh king, again.

5 hozzászólás

1. idézem 2009.02.17. 14:26
   • EdBoy via Google Reader
   Tanulságos.
2. idézem 2009.02.17. 14:26
   • thingol via Google Reader
   jól magyaráz :)
3. idézem 2009.04.26. 12:42
   • B. Péter
   Erről a hálózatos problémáról tudnál írni kicsit részletesebben? Én is iPhone-ra fejlesztek egy szerver-kliens programot, ami nagyméretű fájlokat küld asztali gépről a telefonra. A CFSocket API-t használom, ami a low-level BSD socketekre épülő wrapper és lehetővé teszi, hogy a hálózati forgalmat "integrálni" lehessen a run loop-ba. Te melyik API-t használtad és milyen trükkel sikerült megnövelni a sebességet?
4. idézem 2009.04.27. 11:15
   • Gábor Szántó
   Dettó, CFSocket, CFHTTP* és hasonlók. A trükk forrását nem árulom el, de rávezetlek:
   
   - Akkor lehet használni, ha ki van töltve a Content-length és már a message body-t töltöd, nem a fejléceket.
   
   - Amikor kapsz egy notificationt, akkor ioctl és fionread, ez a két bűvszó.
5. idézem 2009.08.06. 10:45
   • EdBoyWW via Google Reader
   Tanulságos.

Legutolsó hozzászólások

Végre IKEA!: Ági: Heló bárkinek, aki idetéved! A weboldalunk domain-je - a kedvenc áruházunk ügyvédjének nyumására :) - megváltozott: Az új cím: is...

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való