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.
