Quizás el objetivo más importante al diseñar una aplicación web sea que haga correctamente lo que tiene que hacer en el menor tiempo posible. Esto se logra optimizando el proceso completo que implementa la aplicación; al hacer esta tarea, no sólo se mejora la experiencia del usuario final, sino que se optimizan los recursos de procesamiento utilizados.
Una de las áreas fundamentales para lograr tal objetivo es trabajar minuciosamente en el diseño de la base de datos y en la interacción de ésta con la aplicación.
El uso de bases de datos siempre producirá un enlentecimiento en las aplicaciones web (aunque esta caída en el rendimiento es en favor de los beneficios que se obtienen al utilizar una base de datos). De esta manera, siendo conscientes de la caída de rendimiento intrínseca que produce la conexión y las consultas a la base de datos, asegurémosnos que esta caída de performance sea la menor posible. En este artículo se analizarán varios factores a tener en cuenta al desarrollar aplicaciones ASP con bases de datos Access y SQL Server.
Del lado de la base de datos hay cuatro ítems de mayor importancia. Estos cuatro ítems por sí sólos usualmente hacen la diferencia entre una aplicación de base de datos rápida y otra extremadamente lenta. Cometiendo errores aquí, un proceso que usualmente toma 1 segundo en completarse puede tomar minutos o incluso horas!
(1) Seleccionar el tipo de base de datos apropiado
Seleccione el tipo de base de datos apropiado desde el principio. Con el paso del tiempo muchos sitios web comienzan a volverse populares y a aumentar drásticamente la cantidad de visitas. Después de todo ese es el objetivo de todos los que tenemos un sitio web.
Si posee un sitio web popular o proyecta que va a serlo, planee esto desde el principio o esté atento a realizar las actualizaciones necesarias cuando así lo requiera el caudal de actividad.
Mucha gente utiliza ASP + Microsoft Access. ASP y Access son estupendos para desarrollar rápidamente una aplicación web sin la necesidad de ser un super-programador.
Durante los primeros meses, mientras acceden unos pocos visitantes por día al sitio web, todo funciona bárbaro. Access está diseñado para manejar hasta 256 lecturas y 1 escritura a la vez. Si lee y escribe en su base de datos Access con cientos de personas visitando su sitio web, los accesos a la base de datos comenzarán a competir entre sí. Cuando esto ocurre, Access y ASP toman y bloquean gran cantidad de memoria y recursos del servidor, generando una bola de nieve que termina por hacerlo fallar y detenerlo.
Considere el uso de SQL Server, el cual está diseñado para manejar miles de conexiones concurrentes. Access es una pequeña base de datos de oficina que funciona muy bien para sitios web pequeños con no más de 200 sesiones por día.
(2) Diseñar correctamente la estructura de la base de base de datos
Diseñe su base de datos apropiadamente. Una base de datos normalizada es usualmente un buen comienzo. Cree índices para las columnas que son frecuentemente utilizadas como criterio de selección (WHERE ...) u ordenamiento (ORDER BY ...) en las consultas.
Desde el siguiente enlace podrá acceder a un curso gratuito en castellano que desarrolla la teoría de las bases de datos relacionales, como lo son Access y SQL Server:
(3) Optimizar las consultas SQL
Optimice sus consultas SQL. Especificar la lista de columnas, en contraposición a SELECT *, es una mejor práctica que tiene un impacto notable en el rendimiento. Pero construir una consulta que devuelva sólo las filas necesarias y haga un buen uso de los índices existentes hará una gran diferencia.
Por otro lado, deje que la base de datos haga el trabajo. Construya consultas SQL (o procedimientos almacenados en SQL Server) que devuelvan los datos que necesita directamente desde la base de datos en contraposición a la ejecución de complejas consultas SQL a través de la interfaz de ADO.
(4) No almacenar objetos binarios de gran tamaño
No almacene objetos binarios de gran tamaño (como imágenes) en bases de datos a menos que sea irremediablemente necesario, especialmente si utiliza bases de datos Access.
Al recuperar estos objetos a través de recordsets, los mismos son almacenados en memoria ocupando gran cantidad de espacio. En lugar de almacenar imágenes o archivos en las bases de datos, almacene la URL de la imagen/archivo en un campo de texto así puede luego referenciarlo en las páginas de la aplicación.
(5) Las cadenas de conexión
Utilice cadenas de conexión DSN-Less siempre que sea posible. Utilice ADO y OLEDB, no DAO u ODBC. Si necesita utilizar sí o sí un ODBC DSN, utilice un DSN de Sistema (System DNS).
También use exactamente la misma cadena de conexión en toda la aplicación con el objetivo de aprovechar al máximo el uso de agrupación de las conexiones (pooling).
En el caso de utilizar bases de datos SQL Server utilice la directiva Network Library=DBMSSOCN en la cadena de conexión para forzar el uso de TCP/IP en la conexión a la base de datos.
Desde el siguiente enlace podrá obtener una lista de las cadenas de conexión ADO de prácticamente todos los tipos de bases de datos:
http://www.connectionstrings.com
(6) Abrir/Cerrar conexiones en los momentos apropiados
Abra las conexiones justo antes de utilizarlas y ciérrelas tan pronto como deje de necesitarlas. El modo de trabajo debe ser el siguiente: Conectar - Obtener/Guardar Datos - Desconectar. Siempre cierre los objetos de ADO y asígnelos a "nothing". Por ejemplo:
| <%
Dim Conexion, RS
Set Conexion = Server.CreateObject("ADODB.Connection")
Conexion.ConnectionString = [Cadena de Conexión ADO]
Conexion.Open Set RS = Server.CreateObject("ADODB.Recordset")
RS.ActiveConnection = Conexion
RS.Source = "SELECT ..."
RS.Open '...
'Utilizar los datos existentes en el recordset RS
'... RS.Close
Set RS = Nothing
Conexion.Close
Set Conexion = Nothing
%> |
|
(7) Evitar el uso del archivo "adovbs.inc"
Evite el uso del archivo "adovbs.inc". Si necesariamente debe utilizar constantes para las propiedades, defina el subconjunto que necesite. Este archivo define muchísimas constantes, la mayoría de las cuales seguramente nunca utilizará (pero serán cargadas en memoria...).
(8) No almacenar conexiones y recordsets en objetos Session o Application
Muchos programadores se ven tentados a almacenar conexiones y recordsets en objetos Session/Application, así no deben crear instancias en cada página ASP.
En tales casos asumen que esto es más eficiente, pero no lo es. Este es uno de los peores errores que se pueden cometer.
Siempre cree y destruya los objetos de ADO en la misma página. Nunca los mantenga entre sesiones.
Detalles técnicos desde (en inglés):
http://www.learnasp.com/advice/dbsessionapp.asp
(9) Extraer de la base de datos sólo la información necesaria
Sólo extraiga de la base de datos la información que necesita; evite traer columnas innecesarias. Por ejemplo, si posee una tabla con los datos personales de los estudiantes de un colegio y necesita mostrar una lista con los nombres de los mismos no utilice la siguiente consulta:
| SELECT * FROM estudiantes |
|
Será más rápida y consumirá menos recursos una consulta como la siguiente:
| SELECT Apellido, Nombre FROM estudiantes |
|
(10) Utilizar cursores y modos de bloqueo apropiados
Utilice cursores y modos de bloqueo apropiados. Si todo lo que necesita es leer datos de un recordset y mostrarlo en la pantalla (creando una tabla HTML por ejemplo), entonces utilice la configuración por defecto (forward-only, read-only). Comprenda y experimente con las diferentes combinaciones para analizar cómo varía el rendimiento del acceso a datos.
| Tipos de cursores para la propiedad RecordSet.CursorType |
| Tipo | Valor | Descripción |
| adOpenForwardOnly | 0 | Cursor por defecto; permite recorrer el recordset en forma secuencial. |
| adOpenKeySet | 1 | Permite moverse hacia delante y atrás en el recordset. Permite observar las modificaciones en los datos, pero no si existen ingresos de nuevos registros. |
| adOpenDynamic | 2 | Permite moverse en cualquier sentido, viendo cualquier ingreso, modificación, eliminación de datos en el recordset. |
| adOpenStatic | 3 | Permite moverse en cualquier sentido, pero no se verá ningún cambio ocurrido en la tabla. |
| Tipos de bloqueo para la propiedad RecordSet.LockType |
| Tipo | Valor | Descripción |
| adLockReadOnly | 1 | Es el bloqueo por defecto y no permite modificar los registros de la tabla. |
| adLockPessimistic | 2 | Una vez que la tabla es abierta, la misma queda bloqueada para los demás usuarios. |
| adLockOptimistic | 3 | La tabla sólo será bloqueada a los demás usuarios mientras se ejecute una operación de actualización (update). De esta forma la tabla se bloqueará durante menos tiempo que con el método anterior. |
| adBatchOptimistic | 4 | Los registros serán actualizados por lotes (batch). |
(11) Utilizar variables objeto
Una forma garantizada de mejorar el rendimiento mientras se recorre un recordset es utilizar variables objeto apuntando a miembros de las colecciones. Por ejemplo, considere el siguiente recorrido a través del recordset mostrando los campos Nombre y Apellido:
| While Not RS.EOF
Response.Write (RS("Nombre") & " " & RS("Apellido") & "
")
RS.MoveNext
WEnd |
|
Puede hacer que este código se ejecute más rápido reemplazándolo por el siguiente:
| Set Nombre = RS("Nombre")
Set Apellido = RS("Apellido") While Not RS.EOF
Response.Write (Nombre & " " & Apellido & "
")
RS.MoveNext
WEnd |
|
En este último caso se utilizan dos variables asignadas a campos particulares de la colección Fields del recordset (recuerde que la colección Fields es la colección por defecto). Esta forma de trabajo insume menos recursos y funciona más rápido.
(12) La propiedad CacheSize del objeto RecordSet
El tamaño del caché de un recordset es el número de filas que ADO lee a la vez desde la base de datos. Por defecto este valor es 1. Esto significa que, cuando se utilizan cursores, cada vez que se mueve de un registro a otro, el mismo debe ser traído desde la base de datos.
Aumentando el tamaño del caché a 10, por ejemplo, se colocarán en el buffer de ADO de a 10 registros a la vez. Acceder un registro que se encuentra dentro del caché de ADO es más rápido que traerlo desde la base de datos.
Una vez abierto el recodset, puede modificar el tamaño del caché de ADO utilizando la propiedad CacheSize:
No hay un tamaño ideal para asignarle al caché, ya que esto dependerá de la tarea a realizar; pero incrementando su tamaño por encima de 1 invariablemente mejorará el rendimiento.
(13) Una conexión por página
Establecer una conexión a una base de datos consume tiempo. El siguiente es un ejemplo de código mal realizado, ya que abre conexiones a una misma base de datos más de una vez en una misma página:
| <%
Dim Conexion, RS, ID Set Conexion = Server.CreateObject("ADODB.Connection")
Conexion.Open "[cadena de conexión]"
Set RS = Server.CreateObject("ADODB.RecordSet")
RS.Open "SELECT ID FROM tabla1 ORDER BY id DESC", Conexion
ID = RS("id")
RS.Close
Set RS = Nothing
Conexion.Close
Set Conexion = Nothing Set Conexion = Server.CreateObject("ADODB.Connection")
Conexion.Open "[cadena de conexión]"
Conexion.Execute "INSERT INTO tabla1 (id) VALUES(" & id + 1 & ")"
Conexion.Close
Set Conexion = Nothing
%> |
|
El código anterior obtiene el valor del campo "id" de la tabla "tabla1" de la base de datos. Luego crea un nuevo registro con el valor de "id" incrementado en 1. El error de este código es cerrar la conexión a la base de datos entre la ejecución de las consultas SQL.
Ese código puede ser reescrito más apropiadamente de la siguiente manera:
| <%
Dim Conexion, RS, ID Set Conexion = Server.CreateObject("ADODB.Connection")
Conexion.Open "[cadena de conexión]" Set RS = Server.CreateObject("ADODB.RecordSet")
RS.Open "SELECT id FROM tabla1 ORDER BY id DESC", Conexion
ID = RS("id")
RS.Close
Set RS = Nothing Conexion.Execute "INSERT INTO tabla1 (id) VALUES(" & id + 1 & ")" Conexion.Close
Set Conexion = Nothing
%> |
|
La diferencia es que en este caso la conexión a la base de datos sólo se abre una vez, ahorrándose el tiempo de cierre y reapertura.
Fuente :
http://www.argentina-hosting.com
