Meglio bloccare su async con HttpClient piuttosto che usare l'API sincrona come WebRequest?

Question

Meglio bloccare su async con HttpClient piuttosto che usare l'API sincrona come WebRequest?

#1 da (3 voti)
#2 da (0 voti)

2

Sono stato un convinto sostenitore di non bloccare mai il codice asincrono. Ho ritenuto che fosse sempre meglio usare un'API sincrona piuttosto che eseguire la macchina a stati meno efficiente generata dal compilatore anche se non ci sono possibilità di deadlock.

Ma nel caso specifico di System.Net.HttpClient con codice che non può andare fino in fondo asincrono (come un'app console), non è meglio sfruttare il caching della connessione di HttpClient piuttosto che usare qualcosa come WebRequest che deve negoziare la sessione TCP su ogni invocazione?

Sto iniziando a pensare che i vantaggi di riutilizzare HttpClient, anche se blocchi con .Result , superano invece i motivi dell'utilizzo di un'API sincrona.

Si presume naturalmente che HttpClient sia un'istanza condivisa, che venga riutilizzata e funzioni in un ambiente privo di contesto come un'app per console o un nucleo di asp.net.

c# http-request async

posta Crowcoder 12.08.2018 - 14:37

fonte

2 risposte

0

Personalmente, trovo più facile capire e ragionare sul codice filettato rispetto al codice asincrono (non contraddicendo direttamente la tua inclinazione, ma suggerendo che potrei avere un pregiudizio diverso).

Non sono sicuro di cosa intendi per HttpClient che non va 'asincrono fino in fondo'. Non ho guardato all'implementazione .net di HttpClient, ma non c'è ragione per cui non possa essere implementato async fino in fondo - semplicemente usando epoll / wantformultipleple / select.

Per quanto possa capire, HttpClient è la più recente API .NET di MSFT. Solitamente quando MSFT presenta nuove API per qualcosa che già supportano, alla fine deprecano / supportano l'API precedente, quindi preferirei HttpClient per questo motivo.

Se il caching della connessione ti aiuta o meno - dipende dalla natura della tua applicazione. Può aiutare o ferire. Se si effettuano richieste (utilizzando lo stesso client http) allo stesso server, la connessione Keepalive sarà di aiuto. Se NON lo fai, lo farà severamente HURT.

risposta data 12.08.2018 - 16:00

fonte

Leggi altre domande sui tag c# http-request async

Test dei dati in un sistema distribuito Algoritmo per la ricerca di immagini all'interno di immagini [chiuso]

score 3 · Accepted Answer

Non è più necessario bloccare in un'app console.

link

Anche quando lo facevi, puoi semplicemente chiamare MainAsync () da Main e bloccarlo. Non è necessario bloccare una chiamata HttpClient e non si dovrebbe.

I felt it was always better to use a synchronous API than to run the less efficient state machine generated by the compiler

Il tuo sentimento è sbagliato. Anche se il framework su cui stai lavorando non riutilizza il thread mentre sei in attesa, tu puoi ancora utilizzare il thread mentre sei in attesa.