Perché le prestazioni dell'oggetto HttpWebRequest migliorano durante l'utilizzo di Fiddler?

Question

Ho un comportamento molto strano con HttpWebRequest, spero che qualcuno mi possa aiutare. Ho un'app console che fa un po 'di aggregazione utilizzando l'oggetto HttpWebRequest per recuperare i contenuti di un sito Web di destinazione. A causa della natura del requisito, l'app è multithread e tenta di effettuare ovunque tra 10 e 30 connessioni simultanee (sto sperimentando una serie di valori). La richiesta Web effettiva è strutturata come segue:

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;

Comunque, lo strano comportamento è che in circostanze normali l'app sta raggiungendo circa 120 richieste al minuto ma se apro Fiddler salta a circa 600. Usando Windows 7 Resource Monitor posso vedere che l'attività di rete aumenta di conseguenza. Le connessioni TCP per il processo della console ora elencano l'indirizzo remoto come " loopback IPv4 " anziché l'indirizzo IP del server di destinazione (previsto). Mi sono meravigliato del numero massimo di richieste HTTP simultanee consentite dalla macchina, ma la modifica nel registro non sembra fare la differenza.

Quindi la domanda è; di cosa si occupa l'esecuzione di Fiddler che aumenta improvvisamente di cinque volte il throughput e come posso ottenerlo nativamente sulla macchina senza la necessità di lanciare un altro strumento?

Grazie!

Answer 1

Sembra che ora sia stato in grado di ottenere il throughput giusto (per raddoppiare quello che stavo ottenendo con Fiddler aperto in realtà) impostando le connessioni massime in App.config:

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

Molto soddisfatto del risultato, ma sono ancora un po 'sconcertato sul perché avere Fiddler aperto abbia cambiato i risultati in modo così drammatico.

Answer 2

Una cosa che ho notato subito è che non stai implementando usando i blocchi. Ciò aggiunge un fattore di casualità che potrebbe essere moltiplicato per il numero di richieste, quindi ti suggerisco di risolverlo:

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();
        }
    }
}

Successivamente, FYI, Fiddler funge da proxy. Se il proxy predefinito è stato impostato per utilizzare uno script per impostare la configurazione del proxy, allora mi chiedo se avere Fiddler in esecuzione potrebbe non rimuovere il tempo necessario per eseguire l'installazione dello script. Ciò potrebbe accadere solo una volta, piuttosto che su ogni richiesta.

Answer 3

Ho avuto un problema simile al tuo e volevo condividere la mia risoluzione.

In breve, avevo un programma console che stava facendo richieste HTTP e che, dopo circa 15 minuti, sarebbe scaduto. Tuttavia, se avessi usato Fiddler non avrei mai avuto timeout, anche dopo averlo fatto funzionare per giorni consecutivi.

Ho provato a impostare la proprietà maxconnections in App.config, ma non mi è sembrato affatto utile. Sono quindi entrato e ogni singolo riferimento a HttpWebRequest, HttpWebResponse e agli oggetti stream utilizzati per leggere / scrivere dati su questi oggetti all'interno di blocchi.

Che sembra aver fatto il trucco. Sono in esecuzione da quasi 24 ore senza un timeout e senza Fiddler in esecuzione.

Answer 4

Il modo in cui esegui una query provoca la creazione di una nuova sessione per ogni chiamata, che è sovraccarico, è possibile che il violinista aggiunga la sessione alle tue query ....

try

CookieContainer statico privato _cookieContainer = new CookieContainer ();

_httpWebRequest.CookieContainer = _cookieContainer; // con il riciclaggio del cuoco cucina

Answer 5

Abbiamo avuto lo stesso problema, imposta httpWebRequest.PreAuthenticate su true.

non dovresti più avere una risposta 401, quindi aprirai meno connessioni ...

Answer 6

Ho avuto lo stesso problema. Ho scaricato questo: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html Era il motivo della prestazione di HttpWebRequest. Modifica TCPAckFrequency e rovina tutto. L'ho rimosso e ora FUNZIONA.

Answer 7

Per me, stavo impostando request.ProtocolVersion = HttpVersion.Version10;

L'impostazione predefinita per questo è HttpVersion.Version11. Quando ho ripristinato l'impostazione predefinita, le mie richieste sono andate molto più velocemente senza violinista.

Spero che questo aiuti qualcun altro, mi ci è voluto tutto il mattino per capirlo!