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.
la source
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:
Mémoire sur disque (SSD), via socket UNIX
Mémoire à mémoire, via socket UNIX
Mémoire vers / dev / null (ignorer), via le socket UNIX
/ dev / zero à / dev / null, via le socket UNIX
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).
PS
Veuillez noter que ce n'est qu'un simple test utilisant des outils simples, et non un véritable repère approprié .
la source
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:
le
Et mon programme de surveillance est tcpdump - avec l'option -ttt
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
192.168.129.63
notez le 01.XXXXXX - pour le sommeil d'une seconde sur l'interface "lo0"
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)
192.168.129.254
mon routeur - en dehors de l'hôte, pas une machine virtuelle.
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
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).
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é.
la source