Rendimiento de Access contra backend Access en servidor de archivos remoto. Segunda parte.

Servidor

Después de unos días de reflexión (soy padre primerizo de una niña de 7 meses, me merezco un respiro…), voy a empezar a comentar los resultados de las pruebas de rendimiento que he realizado. En el artículo de presentación de la serie de Rendimiento de Access contra backend Access en servidor de archivos remoto os explicaba por encima cómo he realizado las pruebas y el escenario sobre el que las he realizado. En este artículo entraremos un poco más en cada prueba, por lo menos en las primeras pruebas de selección.

Para los que no habéis leído el artículo anterior (os aconsejo que le echéis un vistazo), vuelvo a comentar las características principales del escenario de pruebas y añado alguna más:

  • BackEnd: Base de datos Access alojada en servidor de archivos. 20 tablas correctamente relaciones y normalizadas siguiendo el modelo relacional.
  • FrontEnd: Aplicación Access y VBA.
  • Red: Servidor de archivos en otra provincia, red corporativa dedicada.
  • Tablas de prueba: Se harán pruebas con tablas sin índices y con índices. Se utilizarán 4 tablas con 67.000, 59.000, 3.200 y 9.000 registros respectivamente. Edito: Ver el final del artículo. Tablas de 500.000 registros
  • Consultas: Varios tipos. Devuelven valores entre 41 registros y 372.492 registros (si, habéis leído bien). Edito: Ver el final del artículo. Consultas con 2.000.000 de registros
  • Pruebas: Se realizarán las pruebas en tandas de 100, utilizando bucles para ello. Para que los resultados sean más fiables, se realizará cada tipo de prueba seguido del siguiente, evitando así que influya el estado de la red
  • Concurrencia: Como he comentado, las pruebas principales se realizaron de noche, por lo que no hay usuarios conectados. Gracias a José Antonio Pérez me di cuenta que puede ser importante realizar las mismas pruebas con los usuarios conectados a la base de datos, así que las he realizado desde el equipo de un compañero.

Sin más dilación, empezamos con las pruebas realizadas. En este segundo artículo, las pruebas son sólo con consultas de selección. En esta primera prueba, las tablas tienen índices en los campos clave de búsqueda y la base de datos no tiene usuarios conectados. Al final de las pruebas comentaré los resultados contra una base de datos sin índices y contra una base de datos con una media de 35 usuarios conectados.

Como son varios tipos de consultas, en cada una iré explicando sobre la marcha los métodos utilizados. Como comentaba en el anterior artículo, las tablas sobre las que hago las consultas tienen 67.000, 59.000, 3.200 y 9.000 registros. En cada tipo de consulta detallo el número de registros devueltos.

En este artículo empezaremos con lo más sencillo, consultas contra una única tabla.

Consultas contra una única tabla

Tabla Única

Tabla Única

Llenando el recordsource del formulario con consultas Access contra tablas vinculadas

Simplemente he vinculado las tablas con el servidor y he creado varias consultas.

  • Todo tabla (67.854 registros): Devuelve todos los registros de la tabla.
  • Todo tabla con where puesto (41 registros): Lo mismo pero con parámetros.

Llenando el recordsource del formulario con sentencia SQL directa contra tablas vinculadas

  • Directo SQL (11409 registros): Asigno al recordsource directamente una sentencia SQL.
  • Directo SQL con where puesto (41 registros): Lo mismo pero con parámetros.

Utilizando DAO para abrir las tablas vinculadas

  • Todo tabla con DAO (11409 registros): Abro la tabla con DAO y recupero todos los registros asignándolos al recordset del formulario

Emulando consultas  Pass Through

Este apartado es muy interesante y merece una explicación un poco más larga. Cómo supongo que sabréis, las consultas Pass Through lo que hacen es enviar directamente la consulta al servidor de base de datos (mediante ODBC). Con esto nos evitamos que circulen datos innecesarios por la red y además aprovechamos el mejor procesamiento de los servidores de base de datos.

En principio esto no tiene sentido con un BackEnd Access, pero quería ver si se podía hacer y sobre todo si mejoraba el rendimiento. Así que empecé probando con una consulta Access de paso a través. Como era de esperar, no se puede conectar con un Base de datos Access mediante ODBC así como así. Supongo que se podrá crear un nuevo archivo de origen de datos ODBC, pero yo no he sido capaz de seleccionar una base de datos que está en un servidor de archivos remoto, si alguien lo consigue, que comente por favor.

Así que la única solución «parecida» que he encontrado ha sido crear las consultas en el servidor y acceder a ellas mediante DAO de la siguiente manera:

BaseDatos = "\\RUTA_SERVIDOR\BackEnd.accdb"
pass = "xxxxxxxx"

Set ws = DBEngine.Workspaces(0)
Set dbs = ws.OpenDatabase(BaseDatos, False, False, "MS Access;PWD=" & pass & "")
Set qdf = dbs.QueryDefs("consultaPass")

qdf.ReturnsRecords = True
Set rst = qdf.OpenRecordset
Set Forms!listallena.Recordset = rst
Set qdf = Nothing

O lo que llamo «al vuelo», que es lo mismo pero creando las consultas en el servidor con DAO y borrando después:

BaseDatos = "\\RUTA_SERVIDOR\BackEnd.accdb"
pass = "xxxxxxxx"

Set ws = DBEngine.Workspaces(0)
Set dbs = ws.OpenDatabase(BaseDatos, False, False, "MS Access;PWD=" & pass & "")
Set qdf = dbs.CreateQueryDef("prueba")

qdf.SQL = "SELECT * from tabla"

qdf.ReturnsRecords = True
Set rst = qdf.OpenRecordset
Set Forms!listallena.Recordset = rst
Set qdf = Nothing

dbs.QueryDefs.Delete ("prueba")

De esta forma, emulamos lo que sería una consulta Pass Through. Vamos con las consultas:

  • Todo tabla con DAO emulando Pass al vuelo: Creando la consulta.
  • Todo tabla con DAO emulando Pass: Accediendo a una consulta ya creada.

Conclusiones de esta primera prueba:

Para los que creen que Access es una base de datos de juguete, aquí tenéis las primeras pruebas de que puede que estéis equivocados (en el siguiente artículo os sorprenderéis bastante más…). Varias consultas contra una tabla con 67.000 registros y todas devuelven los resultados en menos de media décima de segundo (quitando la que crea la consulta en el servidor y la vuelve a borrar).

Se puede empezar a ver alguna mejoría en los tiempos de las consultas directas SQL, consultas bien filtradas con parámetros y consultas DAO. De momento no podemos saber si funciona el Pass Through.

No podemos sacar ninguna otra conclusión ya que probablemente los tiempos dependan más del momento de la red que de la optimización de las propias consultas y del método utilizado. Esta prueba es la más sencilla y a lo mejor la menos interesante, pero es un principio y se empieza a ver que tal vez un Backend Access pueda funcionar bien incluso para bases de datos complejas. Veremos qué sucede cuando aumentan los registros devueltos, los usuarios conectados y cuando la carga de procesamiento de la consulta es mayor…

Edito:

Después del reto de @ManejandoDatos, he decidido «aumentar la apuesta» en esta primera prueba. Posteo el reto y los resultados (en posteriores artículos haré las pruebas también con este número de registros además de con los anteriores):

Reto

Reto

Pues de momento no he llegado al millón de registros, pero si a los 500.000. En el siguiente artículo tendremos consultas que devuelven 2.000.000 de registros. Como veréis, dan incluso mejores resultados que la vez anterior. Los tiempos son bajísimos por lo que puede que las pruebas no sean significativas con este tipo de consultas. En el siguiente artículo ya se empezarán a ver grandes diferencias. Ahí van los resultados:

Resultados con 500.000 registros

Resultados con 500.000 registros

photo credit: splorp via photopin cc
The following two tabs change content below.
Llevo más de 10 años programando, sobre todo en Visual Basic y con bases de datos Access. Para mí, VBA y Access siguen siendo herramientas muy potentes. He desarrollado varios proyectos con PHP y MySql. Si sumo las webs que he tenido, probablemente pasaría de 100. Ahora prefiero dedicar todo mi esfuerzo a este blog (aunque sigo manteniendo unas cuantas...). Trabajo en la administración pública (si, soy funcionario), pero he trabajado en pequeñas empresas e incluso en una "grande" de las telecomunicaciones. Ultimamente estoy bastante metido en abrirme nuevos horizontes con C# y .NET. Renovarse o morir!

Deja una respuesta