2010-02-01 21 views
5

Ho un determinato elenco di URL, e faccio un oggetto di richiesta web HTTP e provo a connettermi con esso, ho un 'array' di URL e cerco di connettermi con ognuno di essi. l'obiettivo è vedere quali sono fuori.Qual è il modo più semplice per effettuare più richieste Web di seguito?

Funziona già, ma una richiesta viene avviata appena termina l'ultima, quindi funziona piuttosto lentamente, circa due richieste al secondo.

Mi chiedevo se avrei dovuto fare circa 5 thread lavorando a fianco in background, che lo renderebbero 5 volte più veloce, che è la velocità desiderata (senza sovraccaricare la banda internet condivisa). Ma ho due problemi:

1 - non so nemmeno se è la soluzione migliore per il mio problema. 2 - ho provato alcune volte, ma sono nuovo in .NET framework e non ho mai usato multi-thread. quindi non so come lo farei facilmente.

Ho una funzione start(), e ha un Per che passa attraverso tutta l'esistenza di controllo dell'URL.

dati: VS 08, .NET 3.5, C#.

- [modifica] -

qualcuno può dirmi (con il campione di codice se possibile) come utilizzare cinque (non il maggior numero possibile) le discussioni in BackgroundWorker? che ne dici di iniziare subito dopo l'ultima elaborazione?

risposta

1

Questo è un caso ideale per la classe BackgroundWorker in .NET. Fa uso del pool di thread per eseguire operazioni potenzialmente a esecuzione prolungata in background in modo che il chiamante non debba occuparsi del codice di creazione del singolo thread.

0

Preferisco creare una classe worker che esegua HttpWebRequest e avviarla nella propria thread per ogni connessione. Chiedi alla tua classe operaia di utilizzare un metodo di callback per segnalare che è stato completato. Uso una coda di thread in attesa e un dizionario di thread attivi. I thread che terminano prematuramente a causa di problemi riavviabili come errori di connessione e timeout possono essere rimessi in coda. ManagedThreadId del thread è utile per tenere traccia dei thread.

Probabilmente si desidera anche per aumentare il numero massimo di app di connessioni con l'aggiunta di questo al vostro app.config:

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

ho scelto il 10 come un esempio - si dovrà sperimentare per vedere l'effetto sul velocità effettiva, utilizzo della CPU e utilizzo della memoria.

+0

Attualmente sto usando alcuni backgroundworker, e funziona, ma non sono sicuro che sia davvero tante volte più veloce di quanto abbia i backgroundworker. Questo "app.config" è anche per l'applicazione Windows Form? – Marcelo

+0

L'app.config funziona per winforms. La connessione massima predefinita è 2 per IP, che potrebbe nascondere l'effetto di altri worker di background. –

0

Piuttosto che esplicitamente l'avvio di nuove discussioni te stesso, utilizzare il metodo HttpWebRequest.BeginGetResponse() per eseguire ogni richiesta in modo asincrono, e specificando un metodo di callback:

http://www.developerfusion.com/code/4654/asynchronous-httpwebrequest/

ricordarsi di chiamare risposta.Close() nel metodo di callback in modo da non superare il numero massimo di connessioni simultanee. Questo è preferibile ad aumentare il valore maxconnection app.config, che è contro le linee guida RFC (connessioni max = 2).

Come guida approssimativa, è possibile eseguire circa 8 richieste al secondo su un periodo di 5 secondi utilizzando questo metodo.

+0

Che dire di un'applicazione winform, c'è un modo per massimizzare le richieste web? Ho messo 15 lavoratori (fatto tutto prima di aver postato la tua risposta) e non è 15 volte più veloce .. direi circa 5 volte. Questa limitazione del numero massimo di richieste Web è applicabile all'applicazione winform? come potrei alzarlo? – Marcelo

+0

Il mio post non è specifico per winform o web apps - l'unica differenza è che tutte le modifiche di configurazione andranno in app.config (winform) piuttosto che web.config. Ricorda anche che aumentare il numero di thread non ti darà necessariamente un guadagno lineare in termini di prestazioni, dato che sei vincolato da altri vincoli (i thread condividono le stesse risorse come il tempo della CPU). – Dunc

Problemi correlati