Quelle est la lenteur des sockets TCP par rapport aux canaux nommés sous Windows pour IPC localhost?
Je développe un TCP proxy à mettre devant un service TCP qui devrait gérer entre 500 et 1000 connexions actives à partir d'Internet sauvage).
Le proxy s'exécute sur la même machine que le service et est principalement transparent. Le service ignore pour la plupart le proxy, la seule exception étant la notification de la véritable adresse IP distante des clients.
Cela signifie que, pour chaque socket ouvert entrant TCP socket, il y a deux autres sockets sur le serveur: le deuxième de la paire dans le proxy et celui sur le service réel derrière le proxy.
Les tailles de fenêtre d'envoi et d'enregistrement sur les deux sockets proxy sont définies sur 1024 octets.
Quelles sont les implications de performance à ce sujet? Quelle est la lenteur de cette configuration? Dois-je faire un effort pour changer le service pour utiliser des canaux nommés (ou un autre mécanisme IPC), ou un hôte local TCP est pour la plupart un système efficace) IPC?
La fusion des deux applications n'est pas une option. En ce moment, nous sommes coincés avec la configuration à deux processus.
[~ # ~] modifier [~ # ~] : La raison d'avoir deux processus distincts sur le même matériel est 100% économique. Nous avons un seul serveur et nous ne prévoyons pas d'en obtenir plus (pas d'argent).
Le service TCP est un logiciel hérité de Visual Basic 6 qui a grandi au-delà de nos attentes. Le proxy est C++. Nous n'avons pas le temps, l'argent ni la main-d'œuvre pour réécrire et migrer le code VB6 vers un environnement de programmation moderne.
Le proxy est notre tentative d'atténuer un problème de performances spécifique sur le service, une attaque DDoS que nous recevons de temps en temps.
Le proxy est open source, et voici le code source du projet .
Ce sera le même (ou du moins pas sensiblement différent). Winsock est suffisamment intelligent pour savoir s'il parle à une socket sur le même hôte et, dans ce cas, il court-circuite à peu près tout ce qui se trouve sous IP et copie les données directement de tampon à tampon. En termes de canaux nommés par rapport aux sockets, si vous devez être capable de communiquer avec différentes machines à l'avenir, choisissez des sockets. Si vous savez pertinemment que vous n'aurez jamais besoin de le faire, choisissez celui avec lequel vos développeurs sont le plus familiers ou les plus à l'aise.
Pour quiconque vient le lire plus tard, je souhaite ajouter quelques résultats qui répondent à la question d'origine.
Pour un utilitaire que nous développons, nous avons une classe de mise en réseau qui peut utiliser des canaux nommés, ou TCP avec les mêmes appels.
Voici un transfert de fichier en boucle typique sur notre système de test:
Temps de transfert TCP/IP: 2,5 secondes
Temps de transfert des canaux nommés: 3,1 secondes
Maintenant, si vous sortez de la machine et que vous vous connectez à un ordinateur distant sur votre réseau, les performances des canaux nommés sont bien pires:
Temps de transfert TCP/IP: 12 secondes
Temps de transfert des canaux nommés: 2,5 minutes (oui minutes!)
Je me rends compte que ce n'est qu'un système (Windows 7) Mais je pense que c'est un bon indicateur de la lenteur des canaux nommés ... et il semble que TCP est la voie à suivre.
http://msdn.Microsoft.com/en-us/library/aa178138 (v = sql.80) .aspx
Permettez-moi de vous le résumer. Si vous êtes préoccupé par les performances, utilisez TCP/IP. Mais si vous avez un réseau très rapide et que vous n'êtes pas préoccupé par les performances, les canaux nommés seraient "nets" dans la mesure où cela pourrait vous faire économiser du code.
Sans oublier, si vous vous en tenez à TCP alors vous aurez quelque chose qui peut être mis à l'échelle et même équilibré en charge le moment venu.
À votre santé,
Je sais que ce sujet est très ancien, mais il était toujours pertinent pour moi, et peut-être que d'autres examineront cela à l'avenir également.
J'ai implémenté IPC entre Excel (VBA) et un autre processus sur la même machine, à la fois via une connexion TCP ainsi que via des canaux nommés).
Dans un test de performance rapide, j'ai soumis un message composé de 26 octets du client (Excel) au serveur (pas Excel) et j'ai attendu le message de réponse de l'autre processus (qui comprenait 12 octets dans l'exemple). J'ai exécuté cela une tonne de fois dans une boucle et mesuré le temps d'exécution moyen.
Avec TCP sur localhost (Windows 7, pas de raccourci), une "conversation" (demande + réponse) a pris environ 300-350 microsecondes. L'envoi de données en particulier était assez lent (l'envoi des 26 octets prenait environ 200 microsecondes via TCP). Avec les canaux nommés, une conversation a pris environ 60 microsecondes en moyenne, donc beaucoup plus rapidement.
Je ne sais pas exactement pourquoi la différence était si grande. L'environnement d'entreprise dans lequel j'ai testé cela a un pare-feu strict, des inspections de paquets et ce qui ne l'est pas, donc je PENSE QUE cela peut être dû au fait que même l'hôte local = TCP a subi des mesures de sécurité, ce qui l'a considérablement ralentie, contrairement aux canaux nommés.
TL: DR: Dans mon cas, les canaux nommés étaient environ 5-6 fois plus rapides que TCP pour les petits packages (n'ont pas encore testé avec les plus gros)
Dans le scénario que vous décrivez, les connexions locales TCP sont très peu susceptibles d'être un goulot d'étranglement. Cela entraînera bien sûr des frais généraux, mais cela devrait être négligeable à moins que votre CPU ne soit déjà à chaud.
À une supposition, si l'utilisation du processeur de votre serveur est normalement inférieure à 50% environ (avec le proxy en place), cela ne vaut pas la peine de s'inquiéter de minimiser la surcharge associée aux connexions locales TCP TCP).
Si l'utilisation du processeur est régulièrement supérieure à 80%, vous devriez probablement faire du profilage. Je commencerais par comparer la charge du processeur (ou, mieux encore, les performances, si vous pouvez la mesurer de manière significative) lorsque le proxy est en place et quand il ne l'est pas. Sauf si le proxy effectue un traitement compliqué, la surcharge associée aux connexions supplémentaires TCP représente probablement une fraction importante de la surcharge totale introduite par le proxy, ce qui devrait vous donner au moins une commande) estimation de l'ampleur de combien vous gagneriez en utilisant une forme plus efficace d'IPC.
Quelle est la raison d'avoir un proxy sur la même machine, juste curieux?
En tous cas:
Il existe plusieurs méthodes pour IPC, TCP/IP, les canaux nommés sont comparables en termes de vitesse et de complexité. Si vous voulez vraiment quelque chose qui évolue bien et qui n'a presque pas de surcharge: utilisez la mémoire partagée. Il est préférable de l'utiliser en combinaison avec un algorithme sans verrouillage pour faire avancer les pointeurs (ou utiliser un tampon pour chaque lecteur (le proxy/le service) et écrivain (le service/le proxy)).