Pourquoi les performances de l'objet HttpWebRequest s'améliorent-elles lors de l'utilisation de Fiddler?

StackOverflow https://stackoverflow.com/questions/1022844

  •  06-07-2019
  •  | 
  •  

Question

J'obtiens un comportement très étrange avec HttpWebRequest. J'espère que quelqu'un pourra m'aider. J'ai une application console qui effectue un certain travail d'agrégation en utilisant l'objet HttpWebRequest pour récupérer le contenu d'un site Web cible. En raison de la nature de l’exigence, l’application est multithread et tente de créer entre 10 et 30 connexions simultanées (j’ai expérimenté plusieurs valeurs). La demande Web réelle est structurée comme suit: 

var req = (HttpWebRequest)WebRequest.Create(url);
WebResponse resp = req.GetResponse();
Stream s = resp.GetResponseStream();
var sr = new StreamReader(s, Encoding.ASCII);
string doc = sr.ReadToEnd();
sr.Close();
resp.Close();
return doc;

Quoi qu’il en soit, le comportement étrange est que dans des circonstances normales, l’application réalise environ 120 demandes par minute, mais si j’ouvre Fiddler, elle passe à environ 600. En utilisant le Moniteur de ressources de Windows 7, je peux voir l’activité du réseau augmenter en conséquence. Les connexions TCP du processus de console répertorient maintenant l'adresse distante sous la forme "Boucle IPv4". plutôt que l'adresse IP du serveur cible (attendue). Je me demandais quel était le nombre maximum de requêtes HTTP simultanées autorisées par la machine, mais modifier cela dans le registre ne semble pas faire la différence.

La question est donc: Qu'est-ce qui fait courir Fiddler, qui augmente soudainement le débit de cinq fois, et comment puis-je l'obtenir de manière native sur la machine sans avoir à lancer un autre outil?

Merci!

Était-ce utile?

La solution

On dirait que je suis maintenant capable d’obtenir le débit (doublant le fait que Fiddler soit ouvert en fait) en configurant le nombre maximal de connexions dans le fichier App.config: 

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="30" />
  </connectionManagement>
</system.net>

Très heureux du résultat, mais je ne comprends toujours pas pourquoi l'ouverture de Fiddler a changé les résultats de manière aussi spectaculaire.

Autres conseils

Une chose que j’ai tout de suite remarquée est que vous n’implémentez pas d’utilisation de blocs. Cela ajoute un facteur aléatoire qui peut être multiplié par le nombre de demandes. Je vous suggère donc de résoudre ce problème: 

var req = WebRequest.Create(url);
using (WebResponse resp = req.GetResponse())
{
    using (Stream s = resp.GetResponseStream())
    {
        using (var sr = new StreamReader(s, Encoding.ASCII))
        {
            return sr.ReadToEnd();
        }
    }
}

Ensuite, pour votre information, Fiddler agit en tant que proxy. Si votre proxy par défaut a été configuré pour utiliser un script pour configurer la configuration du proxy, je me demande alors si l'exécution de Fiddler ne risque pas de réduire le temps nécessaire à la configuration du script. Cela pourrait se produire une seule fois, plutôt que sur chaque demande.

J'ai eu un problème similaire au vôtre et je voulais partager ma résolution.

En bref, j’avais un programme de console qui faisait des requêtes HTTP et qui, au bout de 15 minutes environ, expirerait. Cependant, si j’ai utilisé Fiddler, je n’ai jamais eu de dépassement de délai, même après plusieurs jours de travail.

J'ai essayé de définir la propriété maxconnections dans App.config, mais cela ne semblait pas du tout aider. Je suis ensuite entré et chaque référence à HttpWebRequest, HttpWebResponse et aux objets de flux utilisés pour lire / écrire des données sur ces objets dans des blocs.

Cela semble avoir fait l'affaire. Cela fait presque 24 heures que je cours sans temps mort et sans Fiddler.

La façon dont vous interrogez les utilisateurs crée une nouvelle session pour chaque appel, ce qui est une surcharge, il se peut que le violoniste ajoute une session à vos requêtes ....

essayer

private statique CookieContainer _cookieContainer = new CookieContainer ();

_httpWebRequest.CookieContainer = _cookieContainer; // avec le recyclage du cookiecontainer

Nous avons eu le même problème, Définissez votre httpWebRequest.PreAuthenticate sur true.

vous ne devriez plus avoir de réponse 401, vous ouvrirez donc moins de connexions ...

J'ai eu le même problème. J'ai téléchargé ceci: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html C'était la raison de l'exécution du HttpWebRequest. Cela modifie TCPAckFrequency et gâche totalement tout. Je l'ai enlevé et maintenant, ça marche.

Pour moi, je définissais request.ProtocolVersion = HttpVersion.Version10;

Le paramètre par défaut pour cela est HttpVersion.Version11. Lorsque je rétablis les valeurs par défaut, mes requêtes sont beaucoup plus rapides sans fiddler.

J'espère que cela aide quelqu'un d'autre, il m'a fallu toute la matinée pour comprendre cela!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top