Una delle mie domande preferite nei colloqui è "Cosa ti dicono parole come   e   ?" perché apre l'opportunità di avere una discussione interessante con un intervistato... O non lo fa perché galleggiano su questo argomento. A mio parere, è drasticamente importante capire perché utilizziamo questa tecnica. async await  Ho la sensazione che molti sviluppatori preferiscano affidarsi all'affermazione "è la migliore pratica" e utilizzare ciecamente metodi asincroni.  Questo articolo illustra la differenza pratica tra metodi asincroni e sincroni.  Utensili  Applicazione Web API .NET (target di test)  2 database SQL di Azure  2 Azure App Service su Windows (ospita l'applicazione)  Azure App Insights (per raccogliere metriche)  framework   (per simulare il carico utente). locust  Configurazione   Eseguirò un benchmark nel modo seguente. Due istanze di locust indipendenti sono in esecuzione su due macchine. Le istanze di locust simulano un utente che esegue le seguenti operazioni:  L'utente dell'host locust 1 raggiunge l'endpoint   dell'App   riceve la risposta e rimane inattivo per 0,5-1 secondi (il ritardo esatto è casuale). Si ripete fino alla fine dell'esperimento. sincrono Service 1,  L'utente dell'host locust 2 si comporta esattamente nello stesso modo, con una sola differenza: raggiunge l'endpoint   di  asincrono App Service 2.  Sotto il cofano, ogni App Service si connette al proprio database ed esegue una query SELECT che impiega cinque secondi e restituisce alcune righe di dati. Vedere il codice del controller di seguito per i riferimenti. Userò Dapper per effettuare una chiamata al database. Vorrei attirare la vostra attenzione sul fatto che anche l'endpoint asincrono chiama il database in modo asincrono (   ).  QueryAsync<T>  Vale la pena aggiungere che distribuisco lo stesso codice in entrambi i servizi dell'app.  Durante il test, il numero di utenti cresce in modo uniforme fino al numero target (   ). La velocità di crescita è controllata da un parametro   (numero di utenti unici che si uniscono al secondo): più alto è il numero, più velocemente vengono aggiunti gli utenti. Lo   è impostato su 10 utenti/s per tutti gli esperimenti. Numero di utenti Spawn Rate spawn rate  Tutti gli esperimenti sono limitati a 15 minuti.  I dettagli sulla configurazione della macchina sono reperibili nella sezione Dettagli tecnici dell'articolo.  Metrica    : mostra il numero di richieste effettivamente elaborate dall'applicazione e che hanno restituito un codice di stato. richieste al minuto    : mostra il numero di thread consumati dal servizio app. conteggio thread   tempo di risposta mediano, ms  Le linee rosse si riferiscono rispettivamente all'endpoint asincrono, mentre le linee blu all'endpoint sincrono.  Questo è tutto per quanto riguarda la teoria. Cominciamo.   Esperimento n. 1    : 75 (per servizio) numero di utenti  Possiamo osservare che entrambi gli endpoint hanno prestazioni simili: gestiscono circa 750 richieste al minuto con un tempo di risposta medio di 5200 ms.   Il grafico più affascinante di questo esperimento è un trend di thread. Puoi vedere numeri significativamente più alti per l'endpoint sincrono (un grafico blu) — più di 100 thread!   Ciò è previsto, tuttavia, e corrisponde alla teoria: quando arriva una richiesta e l'applicazione effettua una chiamata al database, il thread viene bloccato perché deve attendere il completamento di un roundtrip. Pertanto, quando arriva un'altra richiesta, l'applicazione deve produrre un nuovo thread per gestirla.  Il grafico rosso, il conteggio dei thread dell'endpoint asincrono, dimostra un comportamento diverso. Quando arriva una richiesta e l'applicazione effettua una chiamata al database, il thread torna a un pool di thread invece di essere bloccato. Pertanto, quando arriva un'altra richiesta, questo thread libero viene riutilizzato. Nonostante le richieste in arrivo crescano, l'applicazione non richiede nuovi thread, quindi il loro conteggio rimane lo stesso.  Vale la pena menzionare la terza metrica:   . Entrambi gli endpoint hanno mostrato lo stesso risultato: 5200 ms. Quindi, non c'è differenza in termini di prestazioni.  il tempo di risposta mediano  Adesso è il momento di tirare su la posta.  Esperimento n. 2    : 150 numero di utenti  Abbiamo raddoppiato il carico. L'endpoint asincrono gestisce questa attività con successo: la sua   si aggira intorno a 1500. Il fratello sincrono ha infine raggiunto un numero comparabile di 1410. Ma se guardate il grafico qui sotto, vedrete che ci sono voluti 10 minuti! richiesta al minuto  Il motivo è che l'endpoint sincrono reagisce all'arrivo di un nuovo utente creando un altro thread, ma gli utenti vengono aggiunti al sistema (solo per ricordarti che lo   è di 10 utenti/s) più velocemente di quanto il server web possa adattarsi. Ecco perché ha messo in coda così tante richieste all'inizio.  Spawn Rate  Non sorprende che la metrica   sia ancora intorno a 34 per l'endpoint asincrono, mentre è aumentata da 102 a 155 per quello sincrono. Il   si è degradato in modo simile alla velocità   : il tempo di risposta sincrono era molto più alto all'inizio dell'esperimento. Se avessi mantenuto il test per 24 ore, i numeri mediani sarebbero diventati pari.  del conteggio dei thread tempo di risposta mediano di richiesta al minuto  Esperimento n. 3    : 200 numero di utenti  Il terzo esperimento ha lo scopo di dimostrare le tendenze emerse durante il secondo: possiamo osservare un ulteriore degrado dell'endpoint sincrono.   Conclusione  Utilizzare operazioni asincrone anziché sincrone non migliora direttamente le prestazioni o l'esperienza utente. Innanzitutto, migliora la stabilità e la prevedibilità sotto pressione. In altre parole, aumenta la soglia di carico in modo che il sistema possa elaborare di più prima che si degradi.  Appendice n. 1. Dettagli tecnici  Azure App Service: B1, 100   , 1,75 Gb di memoria, equivalente all'elaborazione della serie A. ACU  Database SQL di Azure: Standard S4: 200 DTU, 500 Mb di spazio di archiviazione.  Impostazioni di connessione SQL: dimensione massima del pool=200.  Appendice n. 2. Note  Per ottenere un risultato di test più pulito, avrei dovuto eseguire i test da 2 VM situate nella stessa rete in cui si trovano i servizi app di destinazione.  Tuttavia, ho dato per scontato che un ritardo di rete avrebbe avuto un impatto su entrambe le app in modo più o meno simile. Pertanto, non può compromettere l'obiettivo principale, ovvero confrontare il comportamento dei metodi asincroni e sincroni.   Appendice n. 3. Esperimento bonus  Cosa ho modificato per forzare l'endpoint sincrono a comportarsi quasi come asincrono e tracciare il grafico sottostante (le condizioni dell'esperimento sono le stesse del terzo: 200 utenti)? 

Read My Stories

Buy Me a Coffee

Questo audio è prodotto nella lingua originale della storia!

Async vs Sync Benchmark (.NET): la differenza tra metodi asincroni e sincroni

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Arron Goolsbey Talks Future of Gaming with AI and Blockchain at Mythical Games

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

Meet Dealscard, Winner of Startups of The Year 2024 in Ghaziabad/Deal Aggregator

Arron Goolsbey Talks Future of Gaming with AI and Blockchain at Mythical Games

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

Meet Dealscard, Winner of Startups of The Year 2024 in Ghaziabad/Deal Aggregator

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps