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

Hazai fejlesztésű DJ alkalmazás iPhone-ra profi DJ-knek: Balazs via Google Reader: grats

Veoh.com: szánalmas!: Milyen Feri: JANI: IE-t használsz? Akkor Tools-Internet Options-Connections-LAN Settings és ott alul... magyarul kb. Eszközök-(internet) soxerencsét...

DJ PLAYER Blue Edition: nev: ilyenkor nem az a jó, ha az ember valóban tologat, meg tekerget, és nem csak tapogat? valódi keverőpultot kellene építened azt hiszem....

Veoh.com: szánalmas!: JANI: Rahzel ez a hotspot-shield valami illegális dolog,vagy megengedett a használata. És bocsi a kérdést de én ehhez hülye vagyok,hogy hol és...

DJ PLAYER Blue Edition: KTamas via Google Reader: meno.