Performance tuning - TCP vs UNIX sockets (diskuse)

[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.