2009-06-21 7 views
10

Ho un comportamento molto strano con HttpWebRequest Spero che qualcuno mi possa aiutare. Ho un'app console che funziona con alcune aggregazioni 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 eseguire ovunque tra 10 e 30 connessioni simultanee (ho sperimentato un intervallo di valori). La richiesta web attuale è strutturato come segue:Perché le prestazioni dell'oggetto HttpWebRequest migliorano durante l'utilizzo di Fiddler?

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; 

In ogni caso, lo strano comportamento è che in circostanze normali l'applicazione sta ottenendo circa 120 richieste al minuto, ma se apro Fiddler salta a circa 600. Utilizzo di Windows 7 Monitoraggio risorse Posso vedere l'attività di rete aumentare di conseguenza. Le connessioni TCP per il processo di console ora elencano l'indirizzo remoto come "IPv4 loopback" piuttosto che l'indirizzo IP del server di destinazione (previsto). Mi sono interrogato sul numero massimo di richieste HTTP simultanee consentite dalla macchina, ma la modifica di questo nel registro non sembra fare la differenza.

Quindi la domanda è; cosa significa eseguire Fiddler che aumenta di cinque volte il throughput e come posso ottenerlo in modo nativo sulla macchina senza dover avviare un altro strumento?

Grazie!

+0

Ho lo stesso problema. Ma ho l'applicazione WinForm .. E non riesco a trovare come risolvere questo problema con l'applicazione winform .. –

risposta

14

Sembra Ho ormai in grado di ottenere il throughput fino (al doppio che mi stavo con Fiddler aprire in realtà) impostando le connessioni Max nel App.config:

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

Molto felice con il risultato, ma sono ancora un po 'disorientato sul motivo per cui avere Fiddler aperto ha cambiato i risultati in modo così drammatico.

+5

Suppongo che il valore predefinito maxconnectionperproxy sia superiore al valore di maxconnection predefinito. – EricLaw

+0

Questo è stato un risparmiatore di vita. Grazie! – Scrappydog

5

Una cosa che ho notato subito è che non state implementando i blocchi. Che aggiunge un fattore di casualità che potrebbe essere moltiplicato per il numero di richieste, quindi vi suggerisco di rimediare:

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

Avanti, FYI, Fiddler agisce come un proxy. Se il tuo proxy predefinito è stato impostato per utilizzare uno script per configurare la configurazione del proxy, allora mi chiedo se avere Fiddler in esecuzione potrebbe non rimuovere il tempo necessario per l'impostazione dello script. Ciò potrebbe accadere solo una volta, piuttosto che su ogni richiesta.

+0

Buon punto John, grazie per averlo fatto. –

1

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

In breve, avevo un programma di console che stava facendo richieste HTTP e, dopo 15 minuti circa, scadeva. Tuttavia, se ho usato Fiddler, non ho mai sperimentato timeout, anche dopo averlo eseguito per giorni interi.

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

Che sembra averlo fatto. Sono in corso da quasi 24 ore senza un timeout e senza Fiddler in esecuzione.

0

Il modo in cui si esegue una query per creare una nuova sessione per ogni chiamata, che è un sovraccarico, potrebbe essere che il violinista aggiunge la sessione alle query ....

provare

private static CookieContainer _cookieContainer = new CookieContainer();

_httpWebRequest.CookieContainer = _cookieContainer; // con il riciclo del cookiecontainer

0

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

non dovrebbe avere 401 risposta più, quindi dovrete aprire meno connessioni ...

0

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

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

Spero che questo aiuti qualcun altro, mi ci è voluto tutta la mattina per capirlo!

Problemi correlati