Una de mis preguntas favoritas en las entrevistas es “¿Qué te dicen palabras como   y   ?” porque abre la oportunidad de tener una conversación interesante con el entrevistado… O no, porque se habla de este tema. En mi opinión, es sumamente importante entender por qué usamos esta técnica. async await  Siento que muchos desarrolladores prefieren confiar en la declaración “es la mejor práctica” y usar métodos asincrónicos ciegamente.  Este artículo muestra la diferencia entre métodos asincrónicos y sincrónicos en la práctica.  Herramientas  Aplicación .NET Web API (objetivo de prueba)  2 bases de datos SQL de Azure  2 Azure App Service en Windows (aloja la aplicación)  Azure App Insights (para recopilar métricas)  marco   (para simular la carga del usuario). locust  Configuración   Ejecutaré un benchmark de la siguiente manera. Dos instancias de Locust independientes se ejecutan en dos máquinas. Las instancias de Locust simulan un usuario que hace lo siguiente:  El usuario del host Locust 1 llega al punto final   del   obtiene la respuesta y permanece inactivo durante 0,5 a 1 segundo (el retraso exacto es aleatorio). Se repite hasta el final del experimento. sincrónico App Service 1,  El usuario del host Locust 2 se comporta exactamente de la misma manera, con una sola diferencia: accede al punto final   de  asincrónico App Service 2.  En segundo plano, cada App Service se conecta a su propia base de datos y ejecuta una consulta SELECT que tarda cinco segundos y devuelve algunas filas de datos. Consulta el código del controlador a continuación para obtener referencias. Usaré Dapper para realizar una llamada a la base de datos. Me gustaría llamar tu atención sobre el hecho de que el punto final asincrónico también llama a la base de datos de forma asincrónica (   ).  QueryAsync<T>  Vale la pena agregar que implemento el mismo código en ambos servicios de aplicación.  Durante la prueba, la cantidad de usuarios crece de manera uniforme hasta alcanzar la cantidad objetivo (   ). La velocidad de crecimiento se controla mediante un parámetro   (cantidad de usuarios únicos que se unen por segundo): cuanto mayor sea la cantidad, más rápido se agregarán los usuarios. La   se establece en 10 usuarios/s para todos los experimentos. Número de usuarios de tasa de generación tasa de generación  Todos los experimentos están limitados a 15 minutos.  Puede encontrar detalles de configuración de la máquina en la sección Detalles técnicos del artículo.  Métrica    : muestra la cantidad de solicitudes que la aplicación realmente procesó y devolvió un código de estado. solicitudes por minuto    : muestra la cantidad de subprocesos que consume el servicio de la aplicación. recuento de subprocesos   tiempo de respuesta medio, ms  Las líneas rojas se refieren al punto final asincrónico y las líneas azules, al sincrónico, respectivamente.  Eso es todo en cuanto a la teoría. Empecemos.   Experimento n.° 1    : 75 (por servicio) Número de usuarios  Podemos ver que ambos puntos finales funcionan de manera similar: manejan alrededor de 750 solicitudes por minuto con un tiempo de respuesta medio de 5200 ms.   El gráfico más fascinante de este experimento es una tendencia de subprocesos. Se pueden ver números significativamente más altos para el punto final sincrónico (un gráfico azul): ¡más de 100 subprocesos!   Sin embargo, esto es lo esperado y coincide con la teoría: cuando llega una solicitud y la aplicación realiza una llamada a la base de datos, el hilo se bloquea porque tiene que esperar a que se complete un viaje de ida y vuelta. Por lo tanto, cuando llega otra solicitud, la aplicación tiene que generar un nuevo hilo para manejarla.  El gráfico rojo (el recuento de subprocesos del punto final asincrónico) demuestra un comportamiento diferente. Cuando llega una solicitud y la aplicación realiza una llamada a la base de datos, el subproceso vuelve a un grupo de subprocesos en lugar de bloquearse. Por lo tanto, cuando llega otra solicitud, este subproceso libre se reutiliza. A pesar de que las solicitudes entrantes aumentan, la aplicación no requiere ningún subproceso nuevo, por lo que su recuento sigue siendo el mismo.  Vale la pena mencionar la tercera métrica:   . Ambos puntos finales mostraron el mismo resultado: 5200 ms. Por lo tanto, no hay diferencia en términos de rendimiento.  el tiempo de respuesta medio  Ahora es el momento de levantar las estacas.  Experimento #2    : 150 Número de usuarios  Duplicamos la carga. El punto final asincrónico maneja esta tarea con éxito: su tasa   ronda las 1500. El hermano sincrónico finalmente alcanzó una cantidad comparable de 1410. Pero si observa el gráfico a continuación, ¡verá que tardó 10 minutos! de solicitudes por minuto  El motivo es que el punto final sincrónico reacciona a la llegada de un nuevo usuario creando otro hilo, pero los usuarios se agregan al sistema (solo para recordarle que la   es de 10 usuarios/s) más rápido de lo que el servidor web puede adaptarse. Es por eso que puso en cola tantas solicitudes desde el principio.  tasa de generación  Como era de esperar, la métrica   sigue rondando los 34 para el punto final asincrónico, mientras que aumentó de 102 a 155 para el sincrónico. El   se degradó de manera similar a la tasa   : el tiempo de respuesta sincrónico era mucho mayor al comienzo del experimento. Si hubiera mantenido la prueba durante 24 horas, los números medios se habrían vuelto iguales.  de recuento de subprocesos tiempo de respuesta medio de solicitudes por minuto  Experimento n.° 3    : 200 Número de usuarios  El tercer experimento tiene como objetivo comprobar las tendencias reveladas durante el segundo: podemos ver una mayor degradación del punto final sincrónico.   Conclusión  El uso de operaciones asincrónicas en lugar de sincrónicas no mejora directamente el rendimiento ni la experiencia del usuario. En primer lugar, mejora la estabilidad y la previsibilidad bajo presión. En otras palabras, aumenta el umbral de carga para que el sistema pueda procesar más antes de degradarse.  Apéndice 1. Detalles técnicos  Azure App Service: B1, 100   , 1,75 Gb de memoria, equivalente de cómputo de la serie A. ACU  Base de datos SQL de Azure: Estándar S4: 200 DTU, 500 Mb de almacenamiento.  Configuración de conexión SQL: Tamaño máximo de grupo = 200.  Apéndice n.° 2. Notas  Para lograr el resultado de prueba más limpio, debería haber ejecutado pruebas desde 2 máquinas virtuales ubicadas en la misma red donde se encuentran los servicios de aplicaciones de destino.  Sin embargo, supuse que un retraso en la red afectaría a ambas aplicaciones de una manera más o menos similar. Por lo tanto, no puede poner en peligro el objetivo principal: comparar cómo se comportan los métodos asincrónicos y sincrónicos.   Apéndice n.° 3. Experimento adicional  ¿Qué hice para forzar al punto final sincrónico a funcionar casi como asincrónico y trazar el gráfico a continuación (las condiciones del experimento son las mismas que en el tercero: 200 usuarios)? 

Read My Stories

Buy Me a Coffee

Este audio es producido en el idioma original de la historia!

Async vs Sync Benchmark (.NET): la diferencia entre métodos asincrónicos y sincrónicos

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps