Mesures de performances moyennes pour la CIB locale

Question

Nous évaluons actuellement différentes méthodes IPC (ou plutôt RPC) pour notre projet actuel, qui n'en est qu'à ses débuts. La performance est un gros problème, et nous faisons donc quelques mesures pour faciliter notre choix. Nos processus qui communiqueront seront sur la même machine.

Une option valide séparée consiste à éviter complètement IPC (en encapsulant les fonctionnalités de l'un des processus dans une DLL .NET et que l'autre l'utilise), mais c'est une option que nous aimerions vraiment éviter, comme ces deux logiciels sont développés par deux sociétés distinctes et nous trouvons très important de maintenir de bonnes «clôtures», qui font de bons voisins.

Nos tests consistaient à transmettre des messages (qui contiennent des objets BLOB de tailles diverses) à travers les limites de processus en utilisant chaque méthode. Ce sont les chiffres que nous obtenons (gamme de performance est en corrélation avec la gamme de la taille des messages):

• Web Service (SOAP sur HTTP):
  • 25-30 Mo/s lorsque les données binaires sont codées en base64 (par défaut)
  • 70-100 MB/s lorsque MMD est utilisé
• Remoting .NET (BinaryFormatter sur TCP): 100-115 MB/s
• groupe de contrôle - méthode DLL appel + mem copie: 800-1000 MB/s

Maintenant, nous avons cherché dans tous les sens pour certains chiffres de performance moyenne pour ces (et d'autres) Méthodes IPC, y compris les performances des sockets de bouclage TCP bruts, mais n'ont pas pu en trouver. Est-ce que ces chiffres ont l'air sains? Pourquoi les performances de ces méthodes IPC locales sont-elles au moins 10 fois plus lentes que la copie de la mémoire? Je ne pouvais pas obtenir de meilleurs résultats même lorsque j'ai utilisé des prises brutes - est-ce que les frais généraux de TCP sont si élevés?

Answer 1

• Plusieurs parties de notre système ont été redessinés afin que nous ne devons pas passer des messages de 30MB autour, mais plutôt 3MB. Cela nous a permis de choisir .NET Remoting avec BinaryFormatter sur des tubes nommés (IpcChannel), ce qui donne des résultats satisfaisants. Notre plan de contingence (au cas où nous aurions besoin de passer des messages de 30 Mo) consiste à passer manuellement des messages protobuf-sérialisés sur des canaux nommés. Nous avons déterminé que cela donne également des résultats satisfaisants.

Answer 2

La mémoire partagée est la plus rapide. Un processus de production peut mettre sa sortie en mémoire partagée entre les processus et informer les autres processus que les données partagées ont été mises à jour. Sous Linux, vous mettez naturellement un mutex et une variable de condition dans la même mémoire partagée afin que les autres processus puissent attendre les mises à jour de la variable de condition.

Answer 3

Les fichiers mappés en mémoire + les objets de synchronisation sont la bonne solution (presque identique à la mémoire partagée, mais avec plus de contrôle). Les sockets sont beaucoup trop lents pour les communications locales. En particulier, il arrive parfois que les pilotes réseau soient plus lents avec localhost que sur le réseau.