12 consejos para aumentar el rendimiento de su aplicación de ASP.NET - Parte 1

Crear y alojar una aplicación web en un servidor web es increíblemente fácil con ASP.NET e IIS. Sin embargo, se pueden modificar muchas oportunidades y configuraciones ocultas para convertirla en una aplicación web de alto rendimiento. En esta publicación de la serie, discutiremos algunos de los trucos menos utilizados o ignorados que se pueden aplicar fácilmente a cualquier aplicación web.

1. Caché del modo kernel

Es una de las principales herramientas ampliamente utilizadas para escribir, lo que hace que las aplicaciones web sean más rápidas. Pero la mayoría de las veces, no lo usamos de manera óptima, lo que deja algunos beneficios importantes.  A medida que cada solicitud de asp.net pasa por varias etapas, podemos implementar el almacenamiento en caché en múltiples niveles como se muestra a continuación.

Podemos ver que la solicitud es recibida primero por HTTP.sys, por lo que si se almacena en caché a nivel del kernel, podemos ahorrar la mayor parte del tiempo que pasamos en el servidor, ya que HTTP.sys un oyente HTTP que se encuentra en el kernel del sistema operativo y escucha la solicitud directamente desde la capa TCP. Podemos ahorrar todo el tiempo empleado en la canalización de IIS/ASP.NET, el ciclo de vida de la página, nuestro código personalizado, el tiempo empleado en la base de datos, etc. Veamos cómo podemos implementarlo.

a)      Vaya a IIS y seleccione el sitio web.

b)      Haga clic en el icono de caché de salida a la derecha debajo de la sección IIS

c)       En el panel derecho, en Acciones, haga clic en Agregar. Se abrirá el siguiente cuadro de diálogo:

Aquí, en el área rodeada de rojo con un círculo, debemos definir las extensiones de archivo que queremos almacenar en caché en el kernel. Para la segunda área encerrada, debemos seleccionar la casilla de verificación. La tercera área encerrada en un círculo muestra que se proporcionan tres opciones para invalidar la caché. En función de nuestros requisitos, podemos configurarlo.

Nota: existen algunas limitaciones para el almacenamiento en caché excesivo a nivel del kernel. Como todas las características de IIS se implementan a nivel de usuario, no podremos aprovechar ninguna de ellas. Consulte este artículo de MSDN para obtener una lista completa del almacenamiento en caché del kernel que no se puede implementar.

2. Modo de canalización (disponible en IIS 7+)

Hay dos modos de canalización disponibles en el nivel del grupo de aplicaciones: clásico e integrado. La versión clásica está disponible para admitir las aplicaciones que se migraron desde IIS6. Entonces, primero, entendamos estos modos. IIS proporciona muchas características que se implementan como módulos en IIS y, de manera similar, muchas características se implementan como un módulo HTTP, que forma parte de la canalización ASP.NET. En el modo clásico, cada solicitud pasa por la canalización de IIS y, a continuación, por la canalización ASP.NET antes de ser atendida.

Hay muchas características que forman parte de ambas canalizaciones, como la autenticación, etc. En el caso del modo integrado, estas dos canalizaciones se fusionan en una sola y todos los módulos (IIS y ASP.NET) se invocan desde el evento único a medida que aparecen, lo que reduce la redundancia y es muy útil en el rendimiento de una aplicación.

Para establecer o actualizar el modo de canalización, seleccione el grupo de aplicaciones deseado y haga clic con el botón derecho en las propiedades.

Aquí, como se indica en la imagen de arriba, podemos configurar el modo de canalización.

Nota: no opte por cambiarlo a ciegas, si su aplicación migró desde IIS6, entonces podría haber alguna dependencia de ella. Después de cambiarlo a fondo, pruébelo antes de seguir adelante.

3. Remove Unused Modules

Cada solicitud ha pasado por la canalización ASP.NET, que contiene muchos módulos HTTP y, al final, un controlador HTTP, que atiende la solicitud como se indica a continuación.

Podemos ver aquí que la solicitud pasa por cada módulo, es procesada por el controlador y luego vuelve a pasar a través de los mismos módulos. Veamos cuántos módulos están, de forma predeterminada, habilitados en una aplicación ASP.NET. He agregado el siguiente código para obtener todos los módulos.

HttpApplication httpApps = HttpContext.ApplicationInstance;
 
//Get list of active modules
HttpModuleCollection httpModuleCollections = httpApps.Modules;
ViewBag.ModulesCount = httpModuleCollections.Count;

Esta colección se puede enlazar a cualquier control y se muestra como:

Muestra dieciocho módulos, algunos de los cuales puede que no estemos utilizando, pero cada solicitud tiene que pasar por estos módulos. Por lo tanto, podemos eliminar estos módulos de la canalización. Para eliminar un módulo, requerimos agregar la configuración en web.config como:

 <system.webServer>
    <modules>
      <remove name="FormsAuthentication" />
      <remove name="DefaultAuthentication" />
      <remove name="OutputCache" />
      <remove name="AnonymousIdentification" />
      <remove name="RoleManager" />
    </modules>
  </system.webServer>

Aquí, enumeramos los módulos que queremos eliminar con la etiqueta remove. Ahora, como agregamos aquí eliminar cinco módulos, la próxima vez que verifiquemos los módulos activos, serán trece.

Nota: para esta demostración, he usado VS 2013, es posible que obtenga un número diferente cuando use otra versión, pero el punto clave es que debemos eliminar todos los módulos que no son necesarios.

4. runAllManagedModulesForAllRequests

Es otra configuración que uno debe haber visto en web.config o applicationHost.config donde se establece globalmente para todas las aplicaciones en ese IIS como:

<modules runAllManagedModulesForAllRequests="true">

Significa que todos los módulos se estarían ejecutando para todas las solicitudes que lleguen a la aplicación, pero normalmente no lo requerimos porque solo debe ejecutarse ASP.NET archivos, no otros archivos como CSS, js, jpg, HTML, etc. Significa que incluso la solicitud de estos recursos pasa por la canalización, lo cual es innecesario para estos archivos, y solo agrega una sobrecarga adicional. Pero no podemos hacer que sea simplemente falso a nivel de aplicación. Por lo tanto, podría haber dos formas:

a)      Cree una aplicación diferente solo para servir estos recursos estáticos y establezca esta configuración como falsa en web.config.

b)      O en la misma aplicación, coloque todos los recursos estáticos en una carpeta y agregue un archivo web.config específico para esa carpeta y hágalo falso.

 

5. No escribas nada en la carpeta c:\inetpub\wwwroot

Un vigilante de archivos examina la carpeta y reinicia el grupo de aplicaciones correspondiente si hay algún cambio en esta carpeta. Esta característica está disponible en IIS; Si se produce algún cambio en Web.config o en cualquier archivo, se reinicia el grupo de aplicaciones para que la aplicación modificada atienda la solicitud. Ahora supongamos que escribe el registro de la aplicación en algún archivo de texto dentro de la carpeta de la aplicación que hace un par de entradas en cada solicitud, el grupo de aplicaciones se reiniciaría tantas veces, lo que sería peligroso para su aplicación. Por lo tanto, no escriba ni cambie nada en esta carpeta hasta que no forme parte de los archivos binarios de la aplicación.

6. Eliminar motores de vista adicional

a) Como sabemos, View Engines es parte del ciclo de vida de la solicitud MVC y es responsable de encontrar la vista y procesarla. También nos permite agregar nuestros propios motores de vista personalizados. Vamos a crear una aplicación MVC predeterminada e intentar devolver una vista que no exista en la solución. Ahora, cuando ejecutamos esta aplicación, muestra el siguiente error.

Muestra que está buscando los archivos razor y aspx en todas las ubicaciones posibles. Pero como sabemos, estamos usando el motor de vista de navaja, por lo que no debe perder el tiempo mirando otros archivos aspx porque ya sabemos que no será parte de la solución. Por lo tanto, deberíamos eliminar todos los motores de vista adicionales.  Necesitamos agregar el siguiente código en el método Application_Start, que está disponible en Global.asax.

// Removing all the view engines
ViewEngines.Engines.Clear();
 
//Add Razor Engine (which we are using)
ViewEngines.Engines.Add(new RazorViewEngine());

Ahora vamos a ejecutarlo de nuevo

Ahora, solo está buscando archivos de afeitar

b)      Si vemos cuidadosamente las pantallas anteriores calientes, entonces sabemos que está buscando archivos c # y vb y dice en nuestras soluciones, nunca hemos usado vb, por lo que, nuevamente, no tiene sentido buscar archivos vbhtml. Para solucionar esto, necesitamos escribir nuestro propio ViewEngine personalizado. Así que vamos a escribir nuestro RazorViewEngine personalizado como:

    public class MyCustomViewEngine : RazorViewEngine
    {
        public MyCustomViewEngine()
        {
            base.AreaViewLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml", "~/Areas/{2}/Views/Shared/{0}.cshtml"};
            base.AreaMasterLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml", "~/Areas/{2}/Views/Shared/{0}.cshtml" };
            base.AreaPartialViewLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml","~/Areas/{2}/Views/Shared/{0}.cshtml"};
            base.ViewLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.MasterLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.PartialViewLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.FileExtensions = new string[] { "cshtml" };
        }
    }

Aquí, lo he heredado de RazorViewEngine, y si vemos el constructor en el, entonces encontramos que allí hemos definido todas las ubicaciones posibles donde puede existir un archivo, lo que incluye también las posibles extensiones de archivo. Ahora usemos este motor de vista en Global.asax.

Y ejecute la aplicación.

Ahora busca archivos de afeitar csharp que tengan sentido y sean amigables con el rendimiento.

Conclusión

En esta publicación, hemos discutido los siguientes seis consejos, que se pueden aplicar fácilmente a cualquier aplicación ASP.NET.

1 –   Caché en modo kernel

2 – Pipeline mode

3 –  Remove unused modules

4 –   runAllManagedModulesForAllRequests

5 –  Don’t write in wwwroot

6 –  Eliminar los motores de vista y el idioma no utilizados

En la próxima publicación de la serie, discutiremos cinco consejos más que funcionarán como un refuerzo del rendimiento para las aplicaciones.