Lokaler Unix-Socket - grobe Vorstellung vom Durchsatz

10

Kennt jemand Durchsatz-Benchmarks / -Messungen für die Verwendung eines lokalen Unix-Sockets für die Kommunikation zwischen Prozessen?

Ich möchte den Leistungsvorteil einer lokalen Datenbankinstanz auf demselben Server wie die Software veranschaulichen, die die Daten aus der Datenbank anfordert, anstatt über eine Netzwerkverbindung kommunizieren zu müssen, insbesondere eine wie Gigabit-Ethernet, von der ich erwarte, dass sie ziemlich langsam ist relativ gesehen.

Bei der Online-Suche habe ich einige Benchmarks gefunden, die die Anzahl der Vorgänge pro Sekunde, aber nicht den Durchsatz pro Sekunde (dh 12 GB / s) anzeigen.

Ich verstehe, dass die Leistung aufgrund von Dingen wie dem Speicherdurchsatz auf einem bestimmten System oder anderen Hardwareeigenschaften variieren wird, aber nur eine grobe Idee ist erforderlich.

Dies bezieht sich nicht auf die lokale TCP-Leistung oder einen Vergleich damit.

performance  socket 
— sa289
quelle
Sie beziehen sich tatsächlich auf die lokale oder Netzwerk-TCP-Leistung. Es ist auch falsch, in Ihrem Szenario zu messen.
— Satō Katsura
@SatoKatsura Ich beziehe mich auf en.wikipedia.org/wiki/Unix_domain_socket
— sa289
Jep. Und wie werden UNIX-Domain-Sockets Ihrer Meinung nach tatsächlich implementiert?
— Satō Katsura
@SatoKatsura Nicht sicher, aber es gibt einen Unterschied basierend auf dem, was ich gelesen habe, auch wenn es nicht Tag und Nacht anders ist. Es gibt auch Benchmarks, die lokale Unix-Domain-Sockets mit lokalen TCP-Sockets vergleichen, die einen signifikanten Leistungsunterschied aufweisen.
— Sa289
Es gibt auch Benchmarks, die lokale Unix-Domain-Sockets mit lokalen TCP-Sockets vergleichen, die einen signifikanten Leistungsunterschied aufweisen. - Können Sie bitte auf einen solchen Benchmark verweisen?
— Satō Katsura

Antworten:

19

Sie können socat für einen einfachen UNIX-Socket-Geschwindigkeitstest verwenden.

Nachfolgend sind die Ergebnisse aufgeführt, die ich auf meinem Laptop erhalte:

#Generate 1GB random file in the "shared memory" (i.e. RAM disk) 
>dd if=/dev/urandom of=/dev/shm/data.dump bs=1M count=1024

Speicher auf Festplatte (SSD) über UNIX-Socket

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock ./data.dump &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.96942 s, 545 MB/s

Speicher zu Speicher über UNIX-Socket

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/shm/data.dump.out &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.927163 s, 1.2 GB/s

Speicher nach / dev / null (verwerfen) über UNIX-Socket

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.720415 s, 1.5 GB/s

/ dev / zero bis / dev / null über den UNIX-Socket

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/zero bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.491179 s, 2.2 GB/s

Wie Sie sehen können, beträgt der Testdurchsatz "Speicher auf Festplatte" sogar 545 MB / s (dh ~ 4360 MB / s), was weit über dem theoretischen Maximaldurchsatz für die 1-GB-Ethernet-Verbindung liegt (~ 1000/8 = 125 MB / s). nicht einmal unter Berücksichtigung von Protokoll-Overheads).

PS

Bitte beachten Sie, dass dies nur ein einfacher Test mit einigen einfachen Werkzeugen ist und kein echter, richtiger Benchmark.

— Zeppelin
quelle
1
Wie ich weiter unten sage - verwechseln Sie Bandbreite nicht mit Durchsatz. socat informiert Sie über die Bandbreite unter "idealen" Bedingungen und darüber, ob die theoretische Bandbreite nicht erreicht wird. Es gibt jedoch keine Informationen über Verzögerungen, die zu einer Verlangsamung der Anwendung führen. Vergleichen Sie die Festplatten-E / A bei 8 Gbit - Stresstest. Das ist das Maximum, das Sie bekommen können - was auch immer X ist. Wenn die Anwendung erreicht, dass "das Medium" Ihr Engpass sein kann. Wenn die Anwendung diese Stufe nicht erreicht, ist der "Engpass" nicht das Medium. Wenn socat bei 1 Gbit maximal ist, die App jedoch nicht - socat sagt mir nicht, was den "Durchsatz" begrenzt.
— Michael Filz
3

Meine "Antwort" ist langwierig - der Schlüssel ist, "Durchsatz" nicht mit "Bandbreite" zu verwechseln - obwohl "Bandbreite" ein begrenzender Faktor sein kann

Kurz gesagt, Ihr Durchsatz kann begrenzt sein, obwohl Ihre Bandbreite nicht gesättigt ist.

Ich musste den Leuten helfen, die Auswirkungen von mehrstufigen Anwendungsstapeln zu verstehen.

Für den Aspekt der TCP-Kommunikation nutze ich Unterschiede in der RTT (Round-Trip-Time).

Für Single-Tier können Sie die lokale IP-Adresse (auf einer Netzwerkkarte) mit lo0 (Loopback) vergleichen.

Bei mehreren Ebenen vergleichen / berechnen Sie die "weiter entfernten" Adressen. Beispielsweise können mehrere Ebenen entweder zwei VMs auf demselben Host oder verschiedene Hosts im selben Rechenzentrum oder verschiedene Rechenzentren sein (vielleicht nur 500 Meter Entfernung, aber immer noch anders).

Zu Ihrer Information: Für viele Anwendungen sind RTT-Unterschiede vernachlässigbar, aber für Anwendungen, die 10-100 Tausend kleine Nachrichten für die RTT-Zeit der Anwendung ausführen, kann dies zu einem Engpass werden.

(Ich habe Situationen gesehen, in denen die "Charge im mehrstufigen Bereich fast 6 Stunden länger dauerte, wenn die RTT im Vergleich zur einstufigen um 0,25 Millisekunden länger war).

Also, einfacher Prüfstand:

Das

for host in 127.0.0.1 192.168.129.63 192.168.129.72 192.168.129.254 192.168.129.71 p5.aixtools.net
do
    wget -q http://${host}/ -O - >/dev/null
    sleep 1
done

Und mein Überwachungsprogramm ist tcpdump - mit der Option -ttt

   -ttt
        Prints a delta (in microseconds) between current and previous line on each dump line.

Eine Mikrosekunde ist eine SI-Zeiteinheit, die einem Millionstel entspricht (0,000001 oder 10−6 oder 1 / 1,000,000). Das heißt, 1000 Mikrosekunden == 1 Millisekunde.

In zwei verschiedenen Fenstern läuft tcpdump:

Für die "lokalen" Zeiten: tcpdump -i lo0 -n -ttt Port 80 und für den "entfernten" tcpdump -I en1 -n -ttt Port 80

In den folgenden Daten ist das Ziel nicht, eine Analyse durchzuführen, sondern zu zeigen, wie Sie Zeitunterschiede identifizieren können, die für den Abschluss von Transaktionen erforderlich sind. Wenn es sich bei einem Anwendungsdurchsatz um serielle Transaktionen handelt, wird der Durchsatz pro "Sek | Min | Stunde" durch die für "Antworten" erforderliche Gesamtzeit beeinflusst. Ich fand es am einfachsten, dies mit dem Konzept der RTT zu erklären - Hin- und Rückfahrt.

Für eine echte Analyse gibt es zusätzliche Dinge zu beachten. Die einzigen Zeilen, die ich zeigen werde, sind der anfängliche TCP-Handshake und das erste ausgehende Paket und die zurückkehrende ACK. Vergleichen Sie zum Vergleich die Deltazeiten, wie lange es dauert, bis die "Antwort" zurückkommt.

127.0.0.1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type 0, capture size 96 bytes
00:00:00.000000 IP 127.0.0.1.42445 > 127.0.0.1.80: S 1760726915:1760726915(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 0>
00:00:00.**000035** IP 127.0.0.1.80 > 127.0.0.1.42445: S 3339083773:3339083773(0) ack 1760726916 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 1482096651>
00:00:00.000013 IP 127.0.0.1.42445 > 127.0.0.1.80: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>
00:00:00.**000014** IP 127.0.0.1.80 > 127.0.0.1.42445: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>

192.168.129.63

Beachten Sie den 01.XXXXXX - für den Ruhezustand von einer Sekunde auf der Schnittstelle "lo0"

00:00:01.006055 IP 192.168.129.63.42446 > 192.168.129.63.80: S 617235346:617235346(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 0>
00:00:00.**000032** IP 192.168.129.63.80 > 192.168.129.63.42446: S 1228444163:1228444163(0) ack 617235347 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 1482096653>
00:00:00.000014 IP 192.168.129.63.42446 > 192.168.129.63.80: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>
00:00:00.**000010** IP 192.168.129.63.80 > 192.168.129.63.42446: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>

192.168.129.72

Virtuelle Maschine auf demselben Host - Beachten Sie, dass die Zeit um 00.000000 beginnt - das erste Paket wird angezeigt (und das 01.XXXXXX für die beiden anderen Adressen unten).

root@x063:[/]tcpdump -i en1 -n -ttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
00:00:00.000000 IP 192.168.129.63.42447 > 192.168.129.72.80: S 865313265:865313265(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096655 0>
00:00:00.**000125** IP 192.168.129.72.80 > 192.168.129.63.42447: S 916041515:916041515(0) ack 865313266 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1481318272 1482096655>
00:00:00.000028 IP 192.168.129.63.42447 > 192.168.129.72.80: . ack 1 win 32761 <nop,nop,timestamp 1482096655 1481318272>
00:00:00.**000055** IP 192.168.129.72.80 > 192.168.129.63.42447: . ack 1 win 65522 <nop,nop,timestamp 1481318272 1482096655>

192.168.129.254

Mein Router - außerhalb des Hosts, keine virtuelle Maschine.

00:00:01.005947 IP 192.168.129.63.42448 > 192.168.129.254.80: S 2756186848:2756186848(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096657 0>
00:00:00.**000335** IP 192.168.129.254.80 > 192.168.129.63.42448: S 2327415811:2327415811(0) ack 2756186849 win 5792 <mss 1460,nop,nop,timestamp 44854195 1482096657,nop,wscale 2,nop,opt-14:03>
00:00:00.000022 IP 192.168.129.63.42448 > 192.168.129.254.80: . ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>
00:00:00.**000090** IP 192.168.129.63.42448 > 192.168.129.254.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>

192.168.129.71

Dieselbe Verbindung wie 192.168.129.72, aber diese ist "besetzt", während "72" inaktiv ist. Ich würde hoffen, dass die ersten Handshakes fast identisch sind

00:00:01.005093 IP 192.168.129.63.42449 > 192.168.129.71.80: S 249227688:249227688(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096659 0>
00:00:00.**000072** IP 192.168.129.71.80 > 192.168.129.63.42449: S 1898177685:1898177685(0) ack 249227689 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1482096104 1482096659>
00:00:00.000022 IP 192.168.129.63.42449 > 192.168.129.71.80: . ack 1 win 32761 <nop,nop,timestamp 1482096659 1482096104>
00:00:00.**000050** IP 192.168.129.71.80 > 192.168.129.63.42449: . ack 1 win 65522 <nop,nop,timestamp 1482096104 1482096659>

mehrere Hopfen

Dies ist derselbe Host, das gleiche Apache-Ergebnis, aber jetzt über die externe Schnittstelle (6 IP-Hops statt direkt) - jetzt können Sie den Effekt von Fern-RTT nutzen. (ps, ich habe die IP-Adresse leicht geändert). Wichtiger: Beachten Sie, dass nach dem ersten Handshake vor dem ersten ACK nach der Rückkehr eines Handshakes zwei ausgehende Pakete vorliegen.

Denken Sie also statt einer 25-ms-RTT daran, dass die RTT 250 Mikrosekunden im Vergleich zu 25 Mikrosekunden beträgt - und Sie haben 500.000 Transaktionen (das sind im Vergleich zu lokalen Transaktionen nur 120 bis 125 Sekunden mehr, und der Durchsatz ist imho vergleichbar. Aber mit Bei 50 Millionen Transaktionen (wie ich es in einer realen Situation getan habe) erhalten Sie zusätzliche 12500 Sekunden - was ungefähr 3,5 zusätzliche Stunden für "buchstäblich" denselben Job hinzufügt (und ein Teil der Lösung für diesen Fall bestand darin, die Pakete größer zu machen - die durchschnittliche Größe war ursprünglich 400-450 Bytes).

Erinnern wir uns, was ich hier zeigen möchte, ist eine ziemlich einfache Möglichkeit, Unterschiede in der Gesamtzeit zu berücksichtigen, die eine Anwendung (Stapeljob) beim Vergleich von mehrschichtigen mit einstufigen Architekturen ausführen muss.

00:00:01.162974 IP 192.168.129.63.42450 > XX.85.86.223.80: S 1331737569:1331737569(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096661 0>
00:00:00.**023962** IP XX.85.86.223.80 > 192.168.129.63.42450: S 3130510306:3130510306(0) ack 1331737570 win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 1482096106 1482096661,nop,opt-14:03>
00:00:00.000025 IP 192.168.129.63.42450 > XX.85.86.223.80: . ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.000062 IP 192.168.129.63.42450 > XX.85.86.223.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.**024014** IP XX.85.86.223.80 > 192.168.129.63.42450: . ack 1 win 65522 <nop,nop,timestamp 1482096107 1482096661>

Eine andere Sache, die ich an der Verwendung von tcpdump "mag", ist ein allgemein verfügbares Programm. Es muss nichts extra installiert werden.

— Michael Filz
quelle
1
und wie hat das etwas mit unix sockets zu tun?
— Nonchip
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.