Aplicaciones ASP.NET de alto rendimiento

Fecha: 04/Ago/2004 (30/07/04)
Autor: Sergioman  e-mail: [email protected]


Desarrollar aplicaciones ASP.NET de alto rendimiento

Como en todas las aplicaciones, siempre ocurre problemas al intentar optimizar el rendimiento de una aplicaci�n, y en ASP.NET no se escapa, es por eso que ciertas pautas a seguir para lograr un rendimiento aceptable.

         Deshabilite el estado de sesi�n cuando no lo utilice.  No todas las aplicaciones requieren un estado de sesi�n por cada usuario, es este caso se debe deshabilitar el estado de sesi�n. Para deshabilitar el estado de sesi�n de una p�gina se pone establece false el atributo EnableSessionState de la directiva @ Page: <%@ Page EnableSessionState=�false� %>. Por defecto, si falta, este atributo tiene el valor true, en el caso de que solo se vayan a usar o leer, pero no crear ni modificar, variables de sesi�n se pone en el atributo de EnableSessionState ReadOnly.

         Elija con cuidado el proveedor de Estados de Sesi�n. Hay tres formas de almacenar los datos de sesi�n: en proceso, fuera de proceso como servicio windows, y fuera de proceso en una base de datos de SQL Server. Cada opci�n tiene sus ventajas: la primera es la mas r�pida y sencilla. Las dos �ltimas son recomendadas si la aplicaci�n se va a ejecutar en varios procesadores o equipos, y cuando no se desean que se pierdan los datos de sesi�n cu�ado se reinicie el servidor o equipo.

         Evite los viajes innecesarios de ida y vuelta al servidor.  Muchas veces resulta tentador, llenar de eventos de controles de servidor a nuestra pagina web. Muchas veces hacer esto hace que pierda tiempo en cada ida y vuelta al servidor. Esto solo debe hacer cuando es necesario acceder a los datos de la base de datos. Muchos procesos no necesitan viajar al servidor para procesarse. Como por ejemplo la validaci�n de campos ingresados por el usuario, este proceso se puede en client-side (lado cliente), con lo cual nos ahorrar�amos viajes de ida y vuelta al servidor.

         Utilice Page.IsPostBack para evitar el procesamiento innecesario en los viajes de ida y vuelta. Nosotros queremos que solo al cargar la p�gina se conecte a una base de datos, y devuelva la respuesta en una grilla, DataGrid, y que no lo haga en cada ida y vuelta al servidor. El evento Page_Load, se ejecuta en cada ida y vuelta al servidor, si nosotros queremos llenar la grilla dentro de este evento, y que solo se cargue la primera vez, se usa la propiedad IsPostBack, para preguntar si es que se carga por primera vez (false), o si viene de un evento en un control de servidor (true). En caso de que Page.IsPostBack=false, se hace la conexi�n a la base de datos y se llena la grilla.

         Usar controles de servidor en las circunstancias adecuadas. Muchas veces parece m�s f�cil usar los controles de servidor, pero muchas veces no es lo m�s recomendable. Supongamos que queremos cargar una imagen que el usuario a pedido. Este se puede hacer en el lado cliente, sin necesidad de ir al servidor. Recordar que cada evento dentro del Page_Load implica un viaje al servidor.

         Guarde el estado de vista de los controles de servidor �nicamente cuando sean necesarios. Todos los controles tienen la caracter�stica de enviar informaci�n del control, sus propiedades, al servidor sin escribir c�digo. Pero hay que evaluar si el envi� es necesario, si por ejemplo enviamos una grilla que despu�s de la vuelta sus propiedades van a ser reemplazadas, degradar�a innecesariamente el rendimiento de la p�gina. Esta propiedad lo tienen todos los controles de servidor, por defecto es true si deseamos desactivarla, tendr�amos que colocar false en la propiedad EnableViewState del control del servidor <asp:datagrid EnableViewSate=�false� ... runat=�server�/>. De manera general se puede desactivar el envi� de los estados de los controles de servidor, colocando en la directiva Page, <%@ Page EnableViewState=�false� %>.

         Utilice Response.Write para la concatenaci�n de cadenas. Seg�n la documentaci�n de ASP.NET, para concatenar cadenas complejas es mas r�pido hacerlo por separado, varias llamadas al m�todo, que hacerlo todo de una sola vez.

Response.Write(�strBegin�)

Response.Write(myTexto)

Response.Write(�strEnd�)  

�hacer los 3 llamados anteriores es mas rapido que hacerlo asi:

Response.Write(�strBegin� & myTexto & �strEnd�)

Conocen alguna forma de probar, cu�l es m�s r�pido?

         No base el c�digo en excepciones. El tratamiento de excepciones degrada significativamente el rendimiento de la aplicaci�n. Si es posible detectar una posible excepci�n, solo con condicionales h�galo.

 �remplace esto

try

   res = 100 / num

End Try

�por esto

if ( num <> 0 )

   res = 100 / num

         Utilice el enlace en tiempo de compilaci�n de Visual Basic .NET o JScript. Muchas veces uno dec�a que bac�n, que f�cil, es trabajar con Visual Basic 6.0, porque no te exige declarar las variables y tampoco exige conversi�n de tipos. Muchas veces esto parece una ventaja, pero a la larga caracter�stica dif�cil de controlar. El nuevo Visual Basic .NET, exige la declaraci�n de variables y la conversi�n explicita de tipos. ASP.NET por compatibilidad con versiones anteriores, deshabilita esta opci�n, para habilitarla colocamos en la directiva Page lo siguiente, <%@ Page Strict=�true� %>. En el caso JScript, permita la conversi�n de tipos, pero esto disminuye el rendimiento en los procesos, es recomendable decirle que tipo de variable es, a que el compilador tarde en averiguar el tipo que deber�a ser.

         Transforme en c�digo administrado los componentes COM llamados frecuentemente. .Net Framework permite trabajar con los componentes COM, tradicionales, pero usar versiones antiguas no mejora el rendimiento. En algunos casos act�a de manera desfavorable al  rendimiento de la aplicaci�n. Cada caso es particular por lo que la mejor manera de decidir si transformar un componente es verificar las numero de llamadas a las funciones del c�digo administrado desde el c�digo no administrado. Es recomendable transformar en c�digo administrado todos los componentes COM que requieran un gran numero de llamadas para interactuar.

         Utilice procedimientos almacenados de SQL Server  para el acceso a datos. El rendimiento de una aplicaci�n mejorara si se usa procedimientos almacenados en lugar de consultas ad-hoc.

         Utilice la clase SqlDataReader para obtener cursores de datos r�pido de s�lo avance. Esta clase ofrece un mejor rendimiento que el DataSet, esto se debe a que SqlDataReader utiliza el formato de transferencia de datos de red nativo de SQL Server para leer los datos directamente de una conexi�n de base de datos.

         Almacene en cach� los datos y resultados de p�ginas siempre que sea posible. Esto le mas rendimiento a la p�gina, que otras caracter�sticas del .Net Framework. Esta opci�n es m�s necesaria para los p�ginas de mayor tr�fico. Esta opci�n le da al sitio alto rendimiento, d�ndole a la aplicaci�n la caracter�stica de ser escalable.

         En las aplicaciones ampliamente basadas en recursos externos, considere la posibilidad de habilitar una matriz de procesos Web en los equipos multiprocesador. El modelo de procesamiento de ASP.NET ayuda a habilitar la estabilidad en los equipos multiprocesador mediante la distribuci�n de trabajos en varios procesos.

         Aseg�rese de deshabilitar el modo de depuraci�n. Recuerde siempre deshabilitar el modo depuraci�n al distribuir  una aplicaci�n de producci�n, ya que cuando esta habilitado el rendimiento de la aplicaci�n se ve muy reducido.

 


ir al ndice