12 consejos para aumentar el rendimiento de las aplicaciones ASP.NET - Parte 2

Esta publicación es la segunda parte de mi publicación anterior donde discutimos seis consejos para mejorar el rendimiento de ASP.NET aplicaciones. En esta publicación, vamos a discutir seis consejos más que podrían ser otra ronda de impulso para el rendimiento de su aplicación. El enlace a la publicación anterior está a continuación.

12 consejos para aumentar drásticamente el rendimiento de ASP.NET aplicación – Parte 1

7. Haz que tu página sea asíncrona

IIS usa el grupo de subprocesos CLR para obtener un subproceso que procesa una solicitud que llega a la aplicación. Digamos, si actualmente hay veinte subprocesos disponibles en el grupo, significa que solo se pueden atender veinte solicitudes en paralelo, y si el procesamiento de solicitudes lleva algún tiempo, podría convertirse en un desastre si se bombardean cientos de solicitudes en unos pocos milisegundos. En este caso, algunas de las solicitudes pueden tardar mucho tiempo y, para otras, pueden devolver el código de estado 404. Para cualquier solicitud, la parte significativa del tiempo desaparece cuando la solicitud sale del alcance actual, como ir a la base de datos y obtener o leer / escribir archivos, llamar a los servicios web, etc. Durante ese período, el subproceso actual sigue esperando hasta que se devuelve la respuesta. Por lo tanto, si hacemos que la página sea asíncrona y las llamadas que consumen mucho tiempo se manejan de forma asíncrona, podemos aumentar considerablemente el rendimiento. Para procesar una página de forma asincrónica, agregue una directiva asincrónica en la página como

Además, ahora escribir código asincrónico se ha vuelto muy fácil con la introducción de las palabras clave async y await. Podemos escribir métodos asincrónicos y podemos usarlo con la ayuda del método RegisterAsyncTask de la página.

8. Aplicación de la suspensión de la piscina

Esta característica se introdujo con Windows Server 2012 R2 y .NET 4.5.1. IIS proporciona una configuración de tiempo de espera de inactividad para los grupos de aplicaciones que, de forma predeterminada, se establecen en 20 minutos. Esto significa que si no hay ninguna solicitud durante 20 minutos, el proceso de trabajo (w3wp.exe) se detendrá para guardar los recursos del servidor. Pero tiene un efecto secundario, ya que como el proceso de trabajo se detiene actualmente, la siguiente solicitud se convierte en una víctima porque mientras se atiende, se requiere que el proceso de trabajo se reinicie e inicialice. El reinicio del proceso de trabajo es un proceso costoso y que requiere mucho tiempo, ya que incluye muchas tareas como el inicio del proceso, la inicialización de configuraciones, la inicialización de asp.net, la carga de los binarios, etc. en la memoria.

Esta función nos permite suspender el proceso en lugar de detenerlo.  Después de la suspensión, libera la mayor parte de la CPU y la memoria que queda disponible para otros sitios alojados en el mismo servidor. Pero se mantiene en un estado en el que si llega una solicitud, se activará rápidamente y comenzará a atender la solicitud. Es similar a la suspensión en las aplicaciones de Windows, donde tenemos conceptos de aplicaciones activas y suspendidas.  Ayuda en dos aspectos, primero nos permite servir de manera más óptima al agregar más aplicación e incluso la solicitud que viene después de un tiempo fuera, también atendida rápidamente sin mucha diferencia con las activas. Podemos configurar en cualquier grupo de aplicaciones como

Select application pool -> advanced settings

9. Eliminar métodos de Global.asax

Global.asax nos proporciona algunos métodos de nivel de aplicación donde algunos se disparan una vez en la primera solicitud, mientras que otros se disparan en cada solicitud. La mayoría de las veces, tenemos métodos vacíos en estos archivos, lo que asp.net obliga a ejecutar esos métodos incluso si no hay código dentro. En cada solicitud, ASP.NET busca si hay algún método disponible en Global.asax y, en caso afirmativo, lo carga y ejecuta en consecuencia. Entonces, como primera cosa, debemos eliminar los métodos vacíos e incluso si podemos eliminar algunos métodos de allí colocando el código en algún otro lugar del ciclo de vida de la página, entonces también será útil.

10. No use SqlDataSource

Evite usar SqlDataSource como origen de datos para controles de datos como GridView. En el caso de GridView, si la paginación está habilitada, al hacer clic en el número de página, recupera todos los registros de la base de datos y, a continuación, aplica la paginación por su cuenta. Lo mismo ocurre con la clasificación. En su lugar, use el enlace de modelo introducido en ASP.NET 4.5, donde podemos usar consultas IQueryable y usar el método select, etc. para devolver la lista de elementos. IQueryable, detrás de escena, optimice y cree las consultas SQL de manera inteligente que obtiene solo los datos requeridos de la base de datos, como solo diez registros, en lugar de todos los registros, u ordene los datos a nivel de base de datos. Eso hace que la paginación y la clasificación sean muy eficientes. Del mismo modo, también podemos usar QueryableDataSource u ObjectDataSource.

11. Usar HTTP Keep-Alive

Es otra joya escondida que reside en el encabezado de respuesta y ayuda a mejorar significativamente el rendimiento de nuestras aplicaciones web. Este encabezado de respuesta mantiene abierta la conexión de cliente y servidor durante un tiempo específico y es utilizada por varias solicitudes. En caso de que la conexión esté abierta, se guarda el tiempo para crear una nueva conexión, lo que permite al servidor enviar la respuesta muy rápidamente. De forma predeterminada, está habilitado y la conexión se abre durante 120 segundos. Si está deshabilitado, se comporta como HTTP 1.0, donde solo se permite una solicitud por conexión. Podemos configurarlo en IIS como

Vaya a IIS -> Seleccione el sitio web deseado> Abrir encabezados de respuesta HTTP -> Haga clic en Establecer encabezados comunes en la pestaña de acción a la derecha

Está habilitado de forma predeterminada (consulte el área encerrada). Compruébelo para comprobar si la aplicación está aprovechando esta característica o no.

Nota: Para IIS 7.5 y versiones posteriores, esta etiqueta de encabezado se quita del encabezado de respuesta y, de forma predeterminada, está habilitada como se describió, pero hay otra etiqueta de encabezado en caso contrario. Si está deshabilitado, en el encabezado de respuesta hay un nuevo encabezado disponible como Conexión: cerrar. Significa que la conexión se cierra después de la solicitud.

12. Remove ETag

Echemos un vistazo a un encabezado de respuesta HTTP

Aquí podemos ver que hay un elemento como ETag (Refiérase Rojo rodeado con un círculo). Tratemos de entender la forma en que se usa. El hecho de que la caché del cliente atienda o no una respuesta depende de dos elementos: uno es el atributo Cache-Control and Expires y otro ETag. ETag es un código hash que se crea en el servidor web para cada contenido y, en caso de que el contenido del archivo cambie, el hash cambia, lo que invalida la caché. En el escenario de granja de servidores web, el hash creado en un servidor diferente será diferente incluso si el contenido es el mismo, ya que el hash también depende del servidor. Por lo tanto, la solicitud no se atenderá desde la caché, incluso si el contenido es el mismo si la solicitud va a otro servidor web. Por lo tanto, es mejor si eliminamos esta etiqueta en sí para obtener un mejor uso de la caché del cliente si la aplicación está alojada en una granja web.

Este consejo es un conjunto de algunos cambios de configuración muy importantes, que pueden tener un impacto significativo en el rendimiento de su aplicación.

un.       Hemos explicado anteriormente que IIS usa el grupo de subprocesos CLR para atender la solicitud. Pongamos un ejemplo, si nuestra aplicación recibe incluso 100 solicitudes simultáneamente y este número de subprocesos no está disponible en el grupo de subprocesos, entonces algunos de ellos tienen que esperar. CLR comienza a crear nuevos subprocesos para asignar cada solicitud. La creación de nuevos subprocesos es un proceso bastante pesado, y en versiones anteriores de .net, la tasa de creación de subprocesos era de dos segundos por subproceso, mientras que en la última versión, es de alrededor de 0,5 segundos. Teniendo en cuenta 0,5 segundos por hilo, la creación de ochenta subprocesos llevará cuarenta segundos, por lo que podemos entender que el tiempo de respuesta variaría al menos de 1 a 40 segundos. Puede imaginar la situación si un número de solicitudes pasa a 500 o 1000.

Hay una configuración en machine.config que es de forma predeterminada como

Que podemos cambiar como:

  maxWorkerThreads = "200" />

Como hemos establecido el recuento de minWorkerThread en 100, se reducirá el tiempo dedicado a crear cada subproceso e IIS estará listo para recibir las solicitudes rápidamente. Tenga en cuenta que la configuración anterior es por núcleo de CPU.

b.      Hay otra configuración importante disponible en applicationHost. Config (se puede establecer en el nivel del grupo de aplicaciones) como maxConcurrentRequestsPerCPU (disponible en IIS 7+) que está en las últimas versiones es 5000, se puede ajustar según los requisitos. Como su nombre indica, establece los límites en los que la aplicación puede procesar el número de solicitudes simultáneas.

c.        maxConnection es otra configuración muy importante. Limita el número de conexiones que se pueden crear a algún otro sistema. El valor predeterminado era 2 en versiones anteriores of.NET. Entra en escena cuando el servidor web realiza una llamada a otra máquina de la red, como servicios de base de datos/wcf, etc. Esto significa que en un momento dado solo se pueden realizar dos conexiones, incluso si tiene servidores de gama alta con buena conectividad. Se puede cambiar a nivel de máquina o a nivel de aplicación como

Aquí lo hemos cambiado a cien. Según los requisitos, podemos aumentar o disminuir, pero se recomienda mantener un número moderado, de lo contrario, podría ser una exageración. Aparte de eso, podemos proporcionar detalles más específicos como la dirección IP o la información del dominio para limitarla a servidores específicos en la red.

Conclusión

En esta serie, discutimos los siguientes doce consejos, la mayoría de ellos podemos aplicarlos fácilmente sin ningún cambio de código que puede mejorar drásticamente el rendimiento de su aplicación web. Estos son:

1. Caché en modo kernel
2. Pipeline mode
3. Remove unused modules
4. runAllManagedModulesForAllRequests
5. Don’t write in wwwroot
6. Eliminación de motores de vista e idioma no utilizados
7. Haz que tu página sea asíncrona
8. Aplicación Suspensión de piscina
9. Quitar métodos de Global.asax
10. No use SqlDataSource
11. Usar HTTP Keep-Alive
12. Remove ETag

Traté de discutir los consejos que normalmente se ignoran, pero que tienen un enorme potencial de mejora del rendimiento y también se pueden aplicar rápidamente. Algunos trucos comunes como la agrupación y la minificación, la compresión de IIS, ViewState, el almacenamiento en caché del cliente son muy importantes pero bien conocidos que no se incluyeron en la serie.