Socket Unix local - idée approximative du débit

Quelqu'un est-il au courant des références / mesures de débit pour l'utilisation d'un socket Unix local pour la communication interprocessus?

Je veux illustrer l'avantage en termes de performances d'avoir une instance de base de données locale sur le même serveur que le logiciel qui demande les données de la base de données par rapport à la nécessité de communiquer via une liaison réseau, en particulier une comme Gigabit Ethernet que je prévois être plutôt lente relativement parlant.

Lors de la recherche en ligne, j'ai trouvé des repères indiquant le nombre d'opérations par seconde, mais pas le débit par seconde (c'est-à-dire 12 Go / s).

Je comprends que les performances varient en raison de facteurs tels que le débit de la mémoire sur un système donné ou d'autres caractéristiques matérielles, mais une idée approximative est nécessaire.

Cela ne fait pas référence aux performances TCP locales ou à une comparaison avec cela.

performance socket

— sa289
source

Vous êtes , en fait, se référant à un réseau local par rapport à la performance de TCP. C'est aussi la mauvaise chose à mesurer dans votre scénario.

— Satō Katsura

@SatoKatsura Je fais référence à en.wikipedia.org/wiki/Unix_domain_socket

— sa289

Ouaip. Et comment pensez-vous que les sockets de domaine UNIX sont réellement implémentés?

— Satō Katsura

@SatoKatsura Pas certain, mais il y a une différence basée sur ce que j'ai lu même si ce n'est pas différent de jour et de nuit. Il existe également des repères comparant les sockets de domaine Unix locaux aux sockets TCP locaux qui montrent une différence de performances significative.

— sa289

Il existe également des repères comparant les sockets de domaine Unix locaux aux sockets TCP locaux qui montrent une différence de performances significative. - Pouvez-vous indiquer un de ces points de référence?

— Satō Katsura

Réponses:

Vous pouvez utiliser socat pour un test de vitesse de socket UNIX simple.

Voici les résultats que j'obtiens sur mon ordinateur portable:

#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

Mémoire sur disque (SSD), via socket UNIX

>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

Mémoire à mémoire, via socket UNIX

>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

Mémoire vers / dev / null (ignorer), via le socket UNIX

>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 à / dev / null, via le socket UNIX

>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

Comme vous pouvez le voir, même le débit de test «mémoire sur disque» est de 545 Mo / s (soit ~ 4360 Mo / s), ce qui est bien en avance sur le débit théorique maximum pour la connexion Ethernet 1 Go (qui est ~ 1000/8 = 125 Mo / s, sans même considérer les frais généraux de protocole).

Veuillez noter que ce n'est qu'un simple test utilisant des outils simples, et non un véritable repère approprié .

— Zeppelin
source

Comme je le dis ci-dessous - ne confondez pas la bande passante avec le débit. socat vous dira la bande passante dans des conditions "idéales", vous dira si la bande passante théorique n'est pas atteinte - mais il ne vous dira rien sur les retards provoquant le ralentissement de l'application. Comparez les E / S disque à 8 Gbit - test de stress. C'est le maximum que vous pouvez obtenir - quel que soit X. Si l'application atteint que "les médias" peuvent être votre goulot d'étranglement. Si l'application n'atteint pas ce niveau - le «goulot d'étranglement» n'est pas le support. Si socat atteint un maximum de 1 Gbit, mais pas l'application - socat ne me dit pas ce qui limite le "débit".

— Michael Felt

Ma «réponse» est longue - leur clé est de ne pas confondre «débit» avec «bande passante» - bien que la «bande passante» puisse être un facteur limitant

En bref, votre débit peut être limité même si votre bande passante n'est pas saturée.

J'ai dû aider les gens à comprendre l'impact des piles d'applications à plusieurs niveaux.

Pour l'aspect des communications TCP, j'utilise les différences de RTT (aller-retour).

Pour un niveau unique, vous pouvez comparer l'adresse IP locale (sur une carte réseau) avec lo0 (bouclage).

Pour les niveaux multiples, vous comparez / calculez les adresses "plus éloignées", par exemple, les niveaux multiples peuvent être soit deux VM dans le même hôte, soit des hôtes différents dans le même centre de données, soit des centres de données différents. (peut-être seulement 500 mètres de distance, mais toujours différent).

Pour info: pour de nombreuses applications, les différences RTT sont négligeables, mais pour les applications qui font 10 à 100 de milliers de petits messages pour le temps RTT d'application peuvent devenir un goulot d'étranglement.

(J'ai vu des situations où le "lot prenait près de 6 heures de plus en multiniveau lorsque le RTT était de 0,25 millisec plus long, par rapport à un seul niveau)

Donc, banc d'essai simple:

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

Et mon programme de surveillance est tcpdump - avec l'option -ttt

   -ttt
        Prints a delta (in microseconds) between current and previous line on each dump line.
Une microseconde est une unité SI de temps égale à un millionième (0,000001 ou 10−6 ou 1/1 000 000). Autrement dit, 1000 microsecondes == 1 milliseconde.

Donc, dans deux fenêtres différentes, tcpdump fonctionne:

Pour les heures "locales": tcpdump -i lo0 -n -ttt port 80 Et pour le "remote" tcpdump -I en1 -n -ttt port 80

Dans les données ci-dessous - le but n'est pas de faire une analyse, mais de montrer comment vous pouvez identifier les «différences» dans le temps requis pour que les transactions se terminent. Lorsqu'un débit d'application correspond à des transactions en série - le débit par "sec | min | heure" est affecté par le temps total requis pour les "réponses". J'ai trouvé cela plus facile à expliquer en utilisant le concept de RTT - aller-retour.

Pour une véritable analyse, il y a d'autres choses à regarder. Ainsi, les seules lignes que je montrerai sont la prise de contact TCP initiale, et le premier paquet sortant et le retour ACK. Pour la comparaison, comparez les temps delta de combien de temps avant le retour de la "réponse".

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

notez le 01.XXXXXX - pour le sommeil d'une seconde sur l'interface "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

machine virtuelle dans le même hôte - notez que l'heure commence à 00.000000 - premier paquet affiché (et le 01.XXXXXX pour les deux autres adresses ci-dessous)

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

mon routeur - en dehors de l'hôte, pas une machine virtuelle.

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

même connexion que 192.168.129.72, mais ceci est «occupé» tandis que «72» est inactif. J'espère que les poignées de main initiales sont presque identiques

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>

plusieurs sauts

c'est le même hôte, le même résultat apache, mais maintenant via l'interface externe (6 sauts IP, plutôt que direct) - vous pouvez maintenant l'effet de RTT longue distance. (ps, j'ai légèrement modifié l'adresse IP). Plus important - notez qu'il y a deux paquets sortants après la prise de contact initiale avant le premier ACK après le retour d'une prise de contact.

Donc, au lieu de 25 msec RTT, pensez que le RTT est de 250 microsecondes, contre 25 microsecondes - et vous avez 500k transactions (ce qui ne représente que 120 à 125 secondes supplémentaires par rapport au local, et le débit est, à mon humble avis, comparable. Mais avec 50 millions de transactions (comme je l'avais fait dans une situation réelle), vous gagnez 12500 secondes supplémentaires - ce qui ajoute environ 3,5 heures supplémentaires pour "littéralement" le même travail (et une partie de la solution dans ce cas était de rendre les paquets plus gros - le la taille moyenne était à l'origine de 400 à 450 octets).

Rappelez-vous, ce que je veux montrer ici est un moyen assez simple de tenir compte des différences de temps global pour qu'une application (tâche par lots) se termine lors de la comparaison d'architectures à plusieurs niveaux avec des architectures à un seul niveau.

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>

Une autre chose que j'aime à propos de l'utilisation de tcpdump est qu'il s'agit d'un programme généralement disponible. Rien de plus n'a besoin d'être installé.

— Michael Felt
source

et comment cela a-t-il quelque chose à voir avec les sockets unix?

— nonchip