Performance tuning - TCP vs UNIX sockets

28.5.2007 23:55 | Přečteno: 2086× | Externí paměť |

Pro komunikaci mezi dvěma procesy je možné (kromě opravdové IPC) použít i sockety. V 1999 jsem s údivem zjistil, že TCP spojení má řádově větší režii než unixové sockety - pokud se dobře pamatuju tak v roce 1999 byl rozdíl i 100 milisekund. Protože opět potřebuju přehazovat data mezi dvěma procesy, zkusil jsem si změřit, jak jsou na tom počítače dneska.

S oblibou používám Webware for Python, který pro komunikaci mezi webovým serverem a aplikačním serverm používá standardně TCP socket. Nastal čas, kdy v serveru něco drhne a protože náhrada TCP socketu za UNIXový je poměrně jednoduchá, zkusil jsem si porovnat, jestli se mi investovaný čas někde vrátí a jestli vůbec nějaký čas ušetřím.

Testovací úkoly jsou: navázat spojení na socket a poslat do něho data (1MB). Testoval jsem UNIX socket a TCP socket na 127.0.0.1

Notebook: Mobile Pentium @ 1GHZ (dual-core)

• navázání spojení: TCP 0.146ms, UNIX 0.064ms
• odeslání 1MiB: TCP 0.959ms, UNIX 2.380ms

Stolní počítač: Pentium II, 231MHz

• navázání spojení: TCP 1.115ms, UNIX 0.4465ms
• odeslání 1MiB: TCP 21.518ms, UNIX 14.0753ms

Ostrý server: Pentium4 1.8Ghz

• navázání spojení: TCP 0.376ms, UNIX 0.144ms
• odeslání 1MiB: TCP 10.591ms, UNIX 9.616ms

Závěr

U dnešních počítačů s dnešními jádry se už takovými blbostmi nemá cenu zabývat .

V roce 1999 byl však rozdíl až 100ms, což už běžný uživatel na interaktivitě programu poznal. V mezičase se asi zlepšily jaderné algoritmy a také výkon procesorů.

socket_speeds.txt - měřicí program, pro data jsem použil aritmetický průměr ze 100 měření.

---

Disclaimer: Cílem nebylo přesně změřit hodnoty propustnosti/latence obou typů socketů, ale pouze zjistit, jestli nahrazením TCP socketu UNIXovým ušetřím nějaký user time. Použitá metoda je hrubě nevědecká a není ani přesná, pro orientaci mi však stačí.

Disclaimer 2: Dočetli jste zápisek v kategorii Externí paměť. Tato kategorie slouží jako sklad pro to, co si chci někam napsat a zatím nemám kam. Pokud tady není myšlenka, je to v pořádku.

       

Komentáře

[xxx]

Jeste by bylo zajimave zjistit, jak to dopadne pokud tech scketu bude treb 1000. Ale musim rict, ze me prekvapilo, ze ty rozdily jsou tak male.

[qiRzT]

Zkusím si tipnout: nemůže to souviset s tím, že při komunikaci přes UNIX sockety není třeba se zabývat ztrátami a tudíž potvrzováním, přeposíláním apod. dat? Že TCP má z principu větší režii?

[xxx]

No a proto bych ocekaval, ze ty rozdily budou vetsi. Nakonec by me vlastne docela zajimalo, jak takovej loopback vypada uvnitr.

[Věroš]

Ty rozdíly tam jsou. Ale jenom v relativních hodnotách - v absolutních se ztratí.

Spíš mne zaráží ta propustnost u TCP na notebooku - jako jediný má víc procesorů, takže při TCP asi jeden procesor data tlačil a druhý tahal, kdežto u UNIXového socketu ne.

[Josef Kufner]

Hezké srovnání. Ale ještě by mě zajímalo, jak je na tom obyčejná roura. Odhaduju, že to bude zhruba stejné, ale i tak... nechcete to někdo testnout?

[Luk]

Kdysi dávno jsem něco takového zkoušel. Na P4 2,5 GHz vycházel round-trip time (čili čas na poslání malého množství dat z jednoho procesu do druhého a zpět) okolo 50 μs bez hyperthreadingu a něco přes 40 μs s ním. Jádro asi 2.6.12.

[Hynek (Pichi) Vychodil]

Vážně? To snad není možné, aby to bylo tak pomalé. Já jsem naměřil 60 μs z jednoho nodu na druhý (z počítače na druhý počítač přes 100Mbps ethernet na běžném komoditním HW) v erlangu a ten používá taky TCP. To vážně nechápu co tam dělaj za kouzla.

[Luk]

Co je na tom divného? Je to z jednoho procesu do druhého a zpět, čili s dvojím přepnutím kontextu (s hyperthreadingem se to realizuje hardwarově, ale i tak...). Žádná kouzla se tam nedějí - když se zanedbá ta různá "omáčka", jedná se o pouhé kopírování z uživatelského prostoru do jádra a naopak. Jediné, co by to teoreticky mohlo brzdit, je aktualizace času přístupu k souboru (jednalo se o pojmenované roury otevřené bez O_NOATIME).

[Hynek (Pichi) Vychodil]

Uf, tak to je to přepnutí kontextu tak hrozně pomalé? Potěš koště :(

[Luk]

Nevím, co znamená "hrozně pomalé". Ale rozhodně nějakou tu mikrosekundu zabere, někdy i o dost více. Kdyžtak tady jsou nějaké výsledky měření.

[peter_h]

Koli (aj) takymto testom som si zalozil svoj blog a urcite to budem testovat, ale tento ani buduci mesiac este nic necakajte, potom budem mat snad viac volna.

[thingie]

Neměří to náhodou skutečný čas mezi spuštěním a koncem, tohlecto? Je to úplně moudré (sice průměr a opakování měření, ale aji tak)?

[Věroš]

jo - jedna chyba tam v měřicím programu je, místo done-start tam patří done-conn, ale na výsledku se skoro nic nemění.

Je to open-source, můžeš to upravit a změnit...

Jinak viz disclaimer.

[cynik]

Napsal jsem aplikaci, kde se prostrednictvim socketu (obou typu) tahaji obrazky. Takze jsem se nekdy kolem roku 2000-2001 zabyval jestli takovyto prenost neni moc pomaly.

Jak si matne vzpominam, tak se ukazalo se, ze rozdil mezi unixovymi a tcp sockety neni vubec zadny a taktez zpomaleni zpusobene tim, ze se data tlaci nejakym uzkym mistem oproti prostemu prekopirovavani pametovych bloku, je nepodstatne. Uz tehdy to tlacilo na starsich pocitacich destiky MB pod vterinku, coz me stacilo, protoze vycitani ze zarizeni trvalo radove vic.

Na samotny prenos ma spis vliv pocet preruseni, ktere je potreba udelat (cili je potreba posilat cele bloky najednou) a kvalita spojeni, jde-li to pres draty a ne jen pres loopback (to ovsem souvisi primo s poctem preruseni). Testoval jsem to pres read/write s tim, ze si velikost prectenych dat urcuji tyhle funkce samy.

V soucasne dobe to pouzivam taky, protoze rozvzeni aplikace na server a klinety je moc sikovna vecicka, a pochopitelne je to rychlejsi, ale sockety stale nejsou ani zdaleka tou nepomalejsi veci, mnohem pomalejsi je disk nebo USB port.

[zde]

Přestože se Unix sockety nevyplatí, X nebo MySQL je stále používají. Proč?

Myslím že u distribuovaných aplikací bude nejlepší zůstat u TCP, a v případě že oba peeři jsou na stejném node, použít sdílenou paměť. Tam by mohl být nárůst oproti TCP docela výrazný- při správně napsaných klientech by to bylo zerocopy z jednoho userspace do druhého. Přepínání procesů ale bude stejný počet, takže jestli je úzké hrdlo toto, ani sdílená paměť moc nepomůže.

[Luk]

Něco je např. tady. Je to sice o FreeBSD, ale základ je stejný.

[Filip Jirsák]

Přestože se Unix sockety nevyplatí, X nebo MySQL je stále používají. Proč?

Příspěvek i komentáře jsou, jestli se nepletu, o Linuxu, ale MySQL nebo X běží i na jiných platformách (např. právě *BSD). Tam může být rozdíl ve výkonu znatelnější.

[Luk]

Jinak samozřejmě MySQL podporuje 4 metody komunikace (TCP socket, Unix socket, roura, sdílená paměť), takže si každý může vybrat to, co mu vyhovuje

[Ondrej 'SanTiago' Zajicek]

Přestože se Unix sockety nevyplatí, X nebo MySQL je stále používají. Proč?

Me jako hlavni vyhoda UNIX socketu prijde, ze mohu pouzit unixova prava pro rizeni pristupu a nemusim se o opravneni starat v programu.

[Věroš]

Já si jen dovolím upozornit, že v blogpostu je napsáno "nevyplatí se mi portovat komunikaci z TCP socketu na UNIX socket" (v tomto konkrétním případě) a rozhodně proti UNIXovým socketům nic nemám.

V době, když nebyly počítače tak odporně rychlé jako dnes, měly UNIXové sockety svoje využití a dodneška mají. Navíc píše Santiago - udělat spolehlivé řízení přístupu na TCP je těžší než na UNIXových socketech.