Come attendere il risultato della chiamata al servizio web asincrono in ASP.NET per le migliori prestazioni

In WebForms Sito ASP.NET (IIS, pool di app singole), ho chiamato il metodo di servizio Web esteso a cui fa riferimento Visual Studio come riferimento di servizio (.NET 4.0). Sfortunatamente devo aspettare le informazioni dal servizio web prima di poter servire la pagina all'utente. Attualmente il servizio Web è chiamato in modo sincrono, quindi il server non può riutilizzare il thread corrente per elaborare altre richieste che hanno un impatto sulle prestazioni.Come attendere il risultato della chiamata al servizio web asincrono in ASP.NET per le migliori prestazioni

Naturalmente posso generare operazioni asincrone per riferimento di servizio in Visual Studio e chiamare BeginGetFoo anziché GetFoo, ma devo ancora attendere in qualche modo il risultato del servizio web.

Ecco che arriva la domanda. Se utilizzo AsyncWaitHandle.WaitOne (come di seguito) sarà meglio in termini di prestazioni dell'intera applicazione dalla chiamata sincrona che uso oggi?

IAsyncResult result = fooSoapClient.BeginGetFoo(); 
result.AsyncWaitHandle.WaitOne(); 
var foo = fooSoapClient.EndGetFoo(result);

E, naturalmente, se l'attesa può essere fatta meglio, sono aperto a suggerimenti.

fonte

2012-02-08 Pol

Si consiglia di leggere la seguente documentazione: http://msdn.microsoft.com/en-us/library/2e08f6yc(v=vs.100).aspx come risposta al proprio questin soggettivo. Non hai fornito informazioni sufficienti –

Per prestazioni ottimali, non aspettare, ma impostare le continuazioni. Il codice che hai postato fa più o meno lo stesso di una chiamata sincrona. – millimoose

@Ramhound - L'ho letto. Di quali informazioni hai bisogno, sarò lieto di aggiungerlo? – Pol

Si desidera utilizzare una pagina asincrona. Vedere "Wicked Code: Scalable Apps with Asynchronous Programming in ASP.NET", anche Asynchronous Pages in ASP.NET 2.0, che parla di servizi Web e attività asincrone con RegisterAsyncTask.

fonte

2012-02-08 14:13:09

Impossibile aggiornare questa risposta abbastanza. – Stilgar

Non riesco a usare 'AddOnPreRenderCompleteAsync()' senza un pesante refactoring perché la chiamata al servizio web occupa una profonda classe di business logic usata in molte pagine. E 'EndEventHandler' può essere eseguito in thread diversi, che è un'altra sfida di refactoring. – Pol

Beh, non puoi fare cose asincrone senza emettere le operazioni asincrone. Il fatto che EndEventHandler venga eseguito in thread diversi non dovrebbe importare a meno che, per qualche motivo, il codice utilizzi i campi ThreadStatic. – Stilgar

Continueresti a tenere il filo. Un'opzione "sicura" sarebbe quella di utilizzare i controller asincroni di ASP.NET MVC: http://www.aaronstannard.com/post/2011/01/06/asynchonrous-controllers-ASPNET-mvc.aspx

Idealmente, non si dovrebbero fare cose a lungo termine su una richiesta web. Avere un servizio di Windows o qualcosa di elaborare l'attività di lunga durata (che potrebbe essere avviata da una richiesta Web rilasciare qualcosa su una coda di messaggi o mettere un'attività in un database) e eseguire il polling dal client usando ajax o qualcosa e quindi aggiornare l'utente quando E 'fatto.

fonte

2012-02-08 14:08:23 ashic

So che posso cambiare l'intero design per evitare questo problema, è facile dire :-) – Pol

Perché diavolo avrebbe aggiunto MVC al suo progetto Web Forms solo per ottenere un comportamento asincrono quando Web Form supporta pagine asincrone (anche servizi e gestori) da prima che il progetto MVC fosse iniziato? – Stilgar

le pagine async/gestori ottengono lo stesso risultato, ma ciò che tali attività a lungo termine non dovrebbero essere eseguite sulla richiesta in ogni caso (il riciclo delle app ecc.). – ashic

Se il refactoring del codice non è accettabile, quindi non è possibile seguire la risposta di @John Saunders, l'unica cosa che si può fare è aumentare il numero di thread per l'applicazione. Questo ti consentirà di scalare meglio, ma ad un certo punto avrà rendimenti decrescenti e inizierai a ferire la performance. Inoltre, se non si hanno utenti in attesa sulla coda delle richieste (ovvero più di 25 utenti simultanei per core sul server) non è necessario fare nulla. La programmazione asincrona nel server Web aiuta solo con la scalabilità ma non le prestazioni effettive per un singolo utente.

fonte

2012-02-08 15:44:40 Stilgar

Come attendere il risultato della chiamata al servizio web asincrono in ASP.NET per le migliori prestazioni

risposta

Problemi correlati