Desarrollar aplicaciones ASP.NET de alto rendimiento
Autor: Sergio - mail:
supersergioman@hotmail.comUniversidad Nacional de Trujillo (U.N.T.) – Peru
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.
Fuente: Documentación Microsoft ASP.NET
Autor: Sergioman
