Langage C#
  1. Langage C#
  3. Mise à l’échelle de plusieurs requêtes HttpWeb?
Intereting Posts
Comment réactiver le pop-up dans Gmail à partir de code C #? Charger les fichiers xml et xslt à partir d’une ressource intégrée dans Saxon 9.4he Fonction de boucle sur appui sur un bouton? Unity3d C # Génération de formulaires dynamics .NET MVC Razor Comment faire pour parcourir les lignes avec un lecteur de données en C #? Référence de l’élément de travail TFS à partir du commentaire de code le code de page en ligne pour les contrôles de serveur ne fonctionne jamais envoyer des SMS gratuits à partir de C # + ASP.NET Chaîne vs chaîne variables statiques dans asp.net/C# Comment comparer 2 listes d’objects et supprimer les éléments qui ne sont pas communs? Réduire toutes les fenêtres ouvertes en C # Comment puis-je vérifier si une chaîne contient un caractère en C #? La propriété personnalisée ne sera pas sauvegardée si elle est modifiée dans la fenêtre de propriété Erreur plusieurs objects avec la même clé DbContext

Mise à l’échelle de plusieurs requêtes HttpWeb?

Je construis une application serveur qui doit exécuter de nombreuses requêtes http sur plusieurs autres serveurs de manière continue. Actuellement, je suis en train de configurer environ 30 threads et d’exécuter en permanence HttpWebRequests de manière synchrone sur chaque thread, pour un débit d’environ 30 requêtes par seconde.

Je suis en effet en train de définir ServicePoint ConnectionLimit dans app.config afin que ce ne soit pas le facteur limitant.

Je dois intensifier cela de manière drastique. À tout le moins, j’ai besoin de plus de puissance processeur, mais je me demande si j’aurais un avantage à utiliser les méthodes asynchrones de l’object HttpWebRequest (par exemple: .BeginGetResponse ()) plutôt que de créer moi-même des threads et d’utiliser les méthodes synchrones (par exemple: .GetResponse ()) sur ces threads.

Si j’utilise les méthodes asynchrones, il est évident que je dois repenser en profondeur mon application. Je me demande donc si quelqu’un pourrait avoir des idées avant de partir et tout recoder, au cas où je déjeunerais.

Merci!

Si vous utilisez Windows NT, la classe System.Net.Sockets.Socket utilise toujours les ports IO Completion pour les opérations asynchrones. Et HTTPWebRequest en mode async utilise des sockets async, et utilisera donc IOCP.

Sans procéder à une parsing comparative détaillée, il est difficile de déterminer si notre goulot d’étranglement se trouve dans HttpWebRequest, dans la stack, dans votre application ou du côté distant, sur le serveur. Asyncc vous assurera de meilleures performances, car il finira par utiliser IOCP sous les couvertures. Et réimplémenter l’application pour async n’est pas si difficile.

Je vous suggère donc de modifier d’abord l’architecture de votre application en asynchrone. Ensuite, voyez combien de débit maximum vous obtenez. Ensuite, vous pouvez commencer l’parsing comparative et déterminer où se trouve le goulot d’étranglement, puis le supprimer.

Le résultat le plus rapide à ce jour pour moi utilise 75 threads exécutant sync httpwebrequest. Environ 140 demandes par seconde sur un serveur Windows 2003, 4core 3ghz, connexion 100 Mo.

Async Httprequest / winsock s’est bloqué à environ 30-50 req / s. N’a pas testé Winsock Sync mais je suppose que cela vous donnerait à peu près le même résultat que httpwebrequest.

Les tests étaient contre 1 200 000 stream de blogs.

Cela faisait mal le mois dernier qu’il serait donc intéressant de savoir si quelqu’un réussissait à tirer davantage de .net?

MODIFIER

Nouveau test: Vous obtenez 350req / sec avec le composant xfserver iocp. Utilisé un tas de threads avec une instance chacun avant tout meilleur résultat. La “partie client” de la bibliothèque contenait quelques bogues vraiment gênants qui rendaient la mise en oeuvre plus difficile que la “partie serveur”. Ce n’est pas ce que vous demandez et ce que vous ne recommandez pas, mais une sorte d’étape.

Suivant: L’ancien test winsock n’utilisait pas les 3.5 SocketAsyncEventArgs, ce sera le suivant.

RÉPONSE

La réponse à votre question, non, cela ne vaudra pas la peine. Les méthodes asynchrones HttpWebRequest déchargent le thread principal tout en conservant le téléchargement en arrière-plan, elles n’améliorent pas le nombre / l’évolutivité des demandes. (du moins pas en 3.5, pourrait être différent en 4.0?)

Cependant, ce qui pourrait être intéressant, c’est de construire votre propre wrapper autour de sockets async / SocketAsyncEventArgs où iocp fonctionne et éventuellement d’implémenter un modèle de début / fin similaire à HttpWebRequest (pour une implémentation la plus simple possible dans le code actuel). L’amélioration est vraiment énorme.