Performances IPC : Pipe nommé vs Socket

Question

Tout le monde semble dire que les named pipes sont plus rapides que les sockets IPC. Dans quelle mesure sont-ils plus rapides ? Je préférerais utiliser les sockets parce qu'ils peuvent faire de la communication bidirectionnelle et sont très flexibles, mais je choisirai la vitesse plutôt que la flexibilité si c'est par un montant considérable.

Answer 1

Je vous suggère de commencer par la voie la plus facile, en isolant soigneusement le mécanisme IPC afin de pouvoir passer de socket à pipe, mais j'opterais définitivement pour socket en premier. Vous devez être sûr que les performances IPC sont un problème avant de procéder à une optimisation préventive.

Et si vous avez des problèmes à cause de la vitesse IPC, je pense que vous devriez envisager de passer à la mémoire partagée plutôt que de passer au pipe.

Si vous voulez faire des tests de vitesse de transfert, vous devriez essayer socat Il s'agit d'un programme très polyvalent qui vous permet de créer presque n'importe quel type de tunnel.

Answer 2

Je vais être d'accord avec shodanex, il semble que vous essayez prématurément d'optimiser quelque chose qui n'est pas encore problématique. A moins que vous connaître les sockets vont être un goulot d'étranglement, je les utiliserais.

Beaucoup de gens qui ne jurent que par les tuyaux nommés font quelques économies, mais avec un code qui passe plus de temps à bloquer pour une réponse IPC qu'à faire un travail utile. Après avoir passé des années à adapter du vieux code à l'ère moderne, je peux dire que l'amélioration de la vitesse est presque nulle.

Si vous pensez vraiment que les sockets vont vous ralentir, utilisez dès le départ la mémoire partagée en faisant attention à la façon dont vous utilisez les verrous. Encore une fois, en réalité, vous pourriez trouver un petit gain de vitesse, mais remarquez que vous en perdez une partie à attendre des verrous d'exclusion mutuelle. Je ne vais pas préconiser un voyage dans l'enfer des futex.

Livre pour livre, les sockets sont (presque) toujours la meilleure solution pour l'IPC en espace utilisateur sous un noyau monolithique et (généralement) la plus facile à déboguer et à maintenir.

Answer 3

Gardez à l'esprit que sockets ne signifie pas nécessairement IP (et TCP ou UDP). Vous pouvez également utiliser les sockets UNIX (PF_UNIX), qui offrent une amélioration sensible des performances par rapport à la connexion à 127.0.0.1.

Answer 4

Comme souvent, les chiffres en disent plus que les sentiments, voici quelques données : Performances de Pipe vs Socket Unix (opendmx.net) .

Ce benchmark montre une différence d'environ 12 à 15% de vitesse plus rapide pour les tuyaux.

Answer 5

Pour une communication bidirectionnelle avec des tuyaux nommés :

• Si vous avez peu de processus, vous pouvez ouvrir deux tuyaux pour deux directions (processusA2ProcessB et processusB2ProcessA)
• Si vous avez de nombreux processus, vous pouvez ouvrir des tuyaux d'entrée et de sortie pour chaque processus (processAin, processAout, processBin, processBout, processCin, processCout etc).
• Ou vous pouvez faire de l'hybride comme toujours :)

Les tuyaux nommés sont assez faciles à mettre en œuvre.

Par exemple, j'ai implémenté un projet en C avec des pipes nommés, grâce à la communication standard basée sur les entrées-sorties de fichiers (fopen, fprintf, fscanf ...), c'était si facile et propre (si c'est aussi une considération).

Je les ai même codés en java (je sérialisais et envoyais des objets par leur intermédiaire !).

Les tuyaux nommés présentent un inconvénient :

• ils ne s'adaptent pas à plusieurs ordinateurs comme les sockets puisqu'ils dépendent du système de fichiers (en supposant que le système de fichiers partagé n'est pas une option).