Połączenie sprzężenia zwrotnego TCP a wydajność gniazda domeny Unix


116

Praca na aplikacji opartej na systemie Android i iOS, która wymaga komunikacji z serwerem działającym na tym samym urządzeniu. Obecnie używam połączenia sprzężenia zwrotnego TCP do komunikacji z aplikacją i serwerem (aplikacja napisana w warstwie użytkownika, serwer napisany w C ++ przy użyciu Android NDK)

Zastanawiałem się, czy zastąpienie komunikacji wewnętrznej gniazdem Unix Domain poprawiłoby wydajność?

A może ogólnie rzecz biorąc, są jakieś dowody / teoria, która dowodzi, że gniazdo domeny Unix zapewniłoby lepszą wydajność niż połączenie zwrotne TCP?


3
Pamiętaj, że gniazda lokalne (gniazda domeny UNIX) wymagają pliku w systemie plików. Użycie adresu sprzężenia zwrotnego TCP utrzymuje wszystko w pamięci. A jeśli musisz używać zdalnych gniazd TCP, może być łatwiej zintegrować inne gniazdo TCP zamiast majstrować przy nowej rodzinie gniazd i adresów.
Jakiś programista,

1
@JoachimPileborg Przy programowaniu tylko dla systemu Linux (Android) istnieje możliwość użycia abstrakcyjnych adresów gniazd domeny UNIX, które nie wymagają pliku w systemie plików.
thuovila,

zobacz stackoverflow.com/questions/14643571/… w przypadku połączenia z systemem Android.
RDX,

8
@Someprogrammerdude Potrzebują pliku w systemie plików, ale to nie znaczy, że wszystko idzie na dysk iz powrotem.
Markiz Lorne

3
@Someprogrammerdude Tylko nazwa pliku, własność i informacje o uprawnieniach są zawsze przechowywane w systemie plików. Cały rzeczywisty transfer danych odbywa się całkowicie w pamięci.
Jesin

Odpowiedzi:


105

Tak, lokalna komunikacja międzyprocesowa przez gniazda domeny unix powinna być szybsza niż komunikacja przez pętle zwrotne połączeń localhost, ponieważ masz mniejszy narzut TCP, patrz tutaj .


12
pierwszy odsyłacz cytuje drugi odsyłacz, który pochodzi z 2005 r. (stary). i obejmuje tylko FreeBSD
Janus Troelsen

7
Ta odpowiedź jest błędna, gdy testowano pętlę zwrotną, tcp na nowoczesnym Linuksie jest tak samo szybki, a czasem szybszy niż UDS. może dostarczyć benchmark, jeśli jest to wymagane
easytiger

10
Ta odpowiedź jest całkowicie poprawna. Interfejs Loopback to nadal TCP, co oznacza, że ​​nadal masz narzut TCP (kontrola przeciążenia, kontrola przepływu, zarządzanie strumieniem (porządkowanie pakietów IP, retransmisja itp.)). Gniazda domeny Unix nie obsługują żadnego z powyższych, ponieważ zostało zaprojektowane od podstaw do działania lokalnie, co oznacza brak problemów z przeciążeniem, brakiem różnic prędkości między serwerem a klientem wymagającym kontroli przepływu, brak porzuconych pakietów itp. Google to w razie wątpliwości , nie jest nowa rzecz.
JSON,

4
A co z lokalnym UDP?
CMCDragonkai

2
biorąc pod uwagę, że pierwszy odsyłacz jest martwy (HTTP 404) ... właśnie dlatego najlepszą praktyką stosu overflow jest przynajmniej podanie krótkiego / zwięzłego odpowiedniego cytatu ze źródłowego adresu URL w momencie pisania odpowiedzi (wtedy, gdy łącze znika krótkie podsumowanie jest nadal dostępne).
Trevor Boyd Smith

80

Ten test porównawczy: https://github.com/rigtorp/ipc-bench zapewnia testy opóźnień i przepustowości dla gniazd TCP, Unix Domain Sockets (UDS) i PIPE.

Here you have the results on a single CPU 3.3GHz Linux machine :

TCP average latency: 6 us

UDS average latency: 2 us

PIPE average latency: 2 us

TCP average throughput: 0.253702 million msg/s

UDS average throughput: 1.733874 million msg/s

PIPE average throughput: 1.682796 million msg/s

Redukcja opóźnień o 66% i prawie 7- krotnie większa przepustowość wyjaśniają, dlaczego większość programów o krytycznym znaczeniu dla wydajności ma własny, niestandardowy protokół IPC.


7
Wydaje mi się, że ich produkt jest odpowiedzią na problem! Może dlatego odpowiadają na te pytania; ponieważ znają odpowiedź.
GreenReaper

To świetna odpowiedź, ponieważ zawiera kilka liczb. Przepustowość z TCP do UNIX jest 350% lepsza, UNIX do PIPE 40% na i5.
ScalaWilliam

13
@GreenReaper Odpowiedź jest rzeczywiście trafna, ale linia naszego produktu Torusware Speedus ... jest dostępna w 2 wersjach, Speedus Lite i Speedus Extreme Performance (EP) nie jest, i sprawia, że ​​całość brzmi jak tania reklama.
Dmitry Grigoriev

3
Spam. I nie, jego produkt nie ma znaczenia przy porównaniu gniazd TCP i Unix. Istnieje wiele zdroworozsądkowych alternatyw dla gniazd - każdy poza tym, o co prosi OP
JSON

Korzystanie z tego narzędzia nie zostało wystarczająco wyjaśnione. Czy jest jakoś strona wyjaśniająca, jak wywołać klienta i serwer?
falkb

40

Test porównawczy Redis pokazuje, że gniazdo domeny unix może być znacznie szybsze niż sprzężenie zwrotne TCP.

Gdy programy testów porównawczych serwera i klienta działają na tym samym komputerze, można użyć zarówno gniazda sprzężenia zwrotnego TCP / IP, jak i gniazda domeny unix. W zależności od platformy gniazda domeny unix mogą osiągnąć około 50% większą przepustowość niż sprzężenie zwrotne TCP / IP (na przykład w systemie Linux). Domyślnym zachowaniem testu porównawczego redis jest użycie sprzężenia zwrotnego TCP / IP.

Jednak ta różnica ma znaczenie tylko wtedy, gdy przepustowość jest wysoka.

Przepustowość na rozmiar danych


8

Gniazda domeny uniksowej są często dwa razy szybsze niż gniazdo TCP, gdy obaj równorzędni są na tym samym hoście. Protokoły domeny uniksowej nie są rzeczywistym zestawem protokołów, ale sposobem wykonywania komunikacji klient / serwer na jednym hoście przy użyciu tego samego interfejsu API, który jest używany dla klientów i serwerów na różnych hostach. Protokoły domeny unix są alternatywą dla metod komunikacji międzyprocesowej (IPC).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.