Unha das miñas preguntas favoritas da entrevista é "Que che din palabras como   e   ?" porque abre a oportunidade de ter unha discusión interesante cun entrevistado... Ou non porque flotan sobre este tema. Na miña opinión, é drasticamente importante entender por que usamos esta técnica. async await  Sinto que moitos desenvolvedores prefiren confiar na declaración "é a mellor práctica" e usar métodos asíncronos cegamente.  Este artigo mostra a diferenza entre os métodos asíncronos e sincrónicos na práctica.  Ferramentas  Aplicación .NET Web API (destino de proba)  2 Bases de datos Azure SQL  2 Azure App Service en Windows (alberga a aplicación)  Azure App Insights (para reunir métricas)  marco   (para simular a carga do usuario). de locust  Configuración   Executarei un benchmark do seguinte xeito. Dúas instancias de langosta independentes están a executarse en dúas máquinas. As instancias de Locust simulan un usuario que fai o seguinte:  O usuario do host de langosta 1 chega ao punto final   do   recibe a resposta e permanece inactivo durante 0,5-1 segundos (o atraso de tempo exacto é aleatorio). Repítese ata o final do experimento. síncrono App Service 1,  O usuario do servidor de langosta 2 compórtase exactamente igual, con só unha diferenza: chega ao punto final   do  asíncrono App Service 2.  Baixo o capó, cada App Service conéctase á súa propia base de datos e executa unha consulta SELECT que leva cinco segundos e devolve algunhas filas de datos. Consulte o código do controlador a continuación para obter referencias. Vou usar Dapper para facer unha chamada á base de datos. Gustaríame chamarlle a atención sobre o feito de que o punto final asíncrono tamén chama á base de datos de forma asíncrona (   ).  QueryAsync<T>  Paga a pena engadir que desprego o mesmo código nos dous servizos da aplicación.  Durante a proba, o número de usuarios crece uniformemente ata o número obxectivo (   ). A velocidade de crecemento está controlada por un parámetro   (número de usuarios únicos para unirse por segundo): canto maior sexa o número, máis rápido se engaden os usuarios. A   está establecida en 10 usuarios/s para todos os experimentos. Número de usuarios Spawn Rate taxa de aparición  Todos os experimentos están limitados a 15 minutos.  Podes atopar detalles da configuración da máquina na sección Detalles técnicos do artigo.  Métricas    : mostra o número de solicitudes que realmente procesou a aplicación e devolveu un código de estado. solicitudes por minuto    : mostra o número de fíos que consome o servizo da aplicación. conta de fíos   tempo medio de resposta, ms  As liñas vermellas fan referencia a asíncronas e as azuis ao punto final síncrono, respectivamente.  Iso é todo sobre a teoría. Imos comezar.   Experimento #1    : 75 (por servizo) número de usuarios  Podemos ver que ambos os puntos finais funcionan de xeito similar: xestionando unhas 750 solicitudes por minuto cun tempo medio de resposta de 5200 ms.   O gráfico máis fascinante deste experimento é unha tendencia de fío. Podes ver números significativamente máis altos para o punto final sincrónico (un gráfico azul): máis de 100 fíos.   Non obstante, iso é de esperar e coincide coa teoría: cando se recibe unha solicitude e a aplicación fai unha chamada á base de datos, o fío está bloqueado porque ten que esperar a que se complete unha viaxe de ida e volta. Polo tanto, cando entra outra solicitude, a aplicación ten que producir un novo fío para xestionala.  O gráfico vermello (o reconto de fíos do punto final asíncrono) demostra un comportamento diferente. Cando chega unha solicitude e a aplicación fai unha chamada á base de datos, o fío volve a un grupo de fíos en lugar de ser bloqueado. Polo tanto, cando entra outra solicitude, este fío libre reutilizase. A pesar de que as solicitudes entrantes crecen, a aplicación non precisa ningún fío novo, polo que o seu reconto segue sendo o mesmo.  Paga a pena mencionar a terceira métrica:   . Ambos os puntos finais mostraron o mesmo resultado: 5200 ms. Polo tanto, non hai diferenzas en termos de rendemento.  tempo medio de resposta  Agora é o momento de arrincar as apostas.  Experimento #2    : 150 Número de usuarios  Duplicamos a carga. O punto final asíncrono xestiona esta tarefa con éxito: a súa taxa   flota en torno a 1500. O irmán síncrono finalmente alcanzou un número comparable de 1410. Pero se observas o gráfico de abaixo, verás que tardou 10 minutos. de solicitude por minuto  O motivo é que o punto final síncrono reacciona á chegada dun novo usuario creando outro fío, pero os usuarios están a ser engadidos ao sistema (só para lembrarche que a   é de 10 usuarios/s) máis rápido do que o servidor web pode adaptarse. Por iso puxo tantas solicitudes en fila ao principio.  taxa de aparición  Como era de esperar, a métrica   aínda está en torno a 34 para o punto final asíncrono, mentres que aumentou de 102 a 155 para o síncrono. O   degradouse de xeito similar á taxa   : o tempo de resposta sincrónica foi moito maior ao comezo do experimento. Se mantivera a proba durante 24 horas, os números medios serían pares.  de conta de fíos tempo medio de resposta de solicitude por minuto  Experimento #3    : 200 Número de usuarios  O terceiro experimento pretende probar as tendencias reveladas durante o segundo; podemos ver unha maior degradación do punto final sincrónico.   Conclusión  Usar operacións asíncronas en lugar de síncronas non mellora directamente o rendemento nin a experiencia do usuario. En primeiro lugar, mellora a estabilidade e previsibilidade baixo presión. Noutras palabras, eleva o limiar de carga para que o sistema poida procesar máis antes de que se degrade.  Apéndice #1. Detalles técnicos  Azure App Service: B1, 100   , 1,75 Gb de memoria, equivalente de computación da serie A. ACU  Azure SQL Database: Standard S4: 200 DTU, 500 Mb de almacenamento.  Configuración da conexión SQL: Tamaño máximo do grupo = 200.  Apéndice #2. Notas  Para conseguir o resultado máis limpo da proba, debería ter executado probas desde 2 máquinas virtuales situadas na mesma rede onde se atopan os servizos de aplicacións de destino.  Non obstante, asumín que un atraso de rede afectaría a ambas as aplicacións dun xeito máis ou menos similar. Polo tanto, non pode poñer en perigo o obxectivo principal: comparar como se comportan os métodos asíncronos e sincrónicos.   Apéndice #3. Experimento extra  Que piratei para forzar o punto final síncrono a funcionar case como asíncrono e representar o gráfico a continuación (as condicións do experimento son as mesmas que no terceiro: 200 usuarios)? 

Read My Stories

Buy Me a Coffee

Este audio está producido na lingua orixinal da historia!

Async vs Sync Benchmark (.NET): a diferenza entre os métodos asíncronos e síncronos

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Society Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Gaming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Society Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Gaming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps