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

Pruebas

En el primer artículo sobre rendimiento de bases de datos Access contra SGBD de servidor hablaba sobre conceptos teóricos para mejorar el rendimiento de un FrontEnd Access conectado a una base de datos de servidor (SQL-Server, Oracle, SQL-Azure, etc.).

Utilicé bastante documentación tanto de Microsoft como de foros especializados y basé el artículo en experiencias de otra gente y en recomendaciones básicas de bases de datos. Pero claro, me quedaban un par de «espinitas» clavadas:

  • Probar por mí mismo todo esto
  • ¿Qué pasa cuando de backend tenemos una base de datos Access en un servidor de archivos?

La primera parte podía resultar relativamente sencilla con herramientas como por ejemplo SQL-Server Profiler y seguro que hay pruebas ya realizadas. El problema sería probablemente interpretar los resultados y disponer de un servidor de pruebas con cada una de las plataformas. De momento lo dejo para más adelante, pero algo estamos preparando con Ángel de AccesyExcel.com y Windows Azure, que a partir de ahora se pasa a llamar Microsoft Azure (ya era hora), evitando así las confusiones.

La segunda parte era bastante complicada ya que Access no tiene ninguna herramienta para medir el rendimiento de las consultas. Por mucho que he investigado, no he encontrado nada que se parezca al Profiler y las herramientas de análisis de rendimiento de Access son muy básicas y teniendo la base de datos medianamente bien construida, no dan nada de información.

La contrapartida en este caso es que puedo probar directamente ya que como sabéis, llevo trabajando con bases de datos Access muchos años y tengo varias aplicaciones ya implementadas contra servidores de archivos, con redes lo suficientemente grandes como para que las pruebas sean significativas. Así que solo me quedaba idear algo para medir el rendimiento…

Supongo que habrá formas mucho mejores de medir rendimientos de consultas (aunque dudo que existan en Access) pero creo que al final, lo que importa son los tiempos. Por ello, decidí desarrollar una aplicación sencillita que midiera el tiempo que tarda en ejecutarse una consulta. Es algo que no parece complicado, pero la verdad es que me costó llegar a desarrollar algo que funcionara correctamente.

Es bastante fácil hacerlo cuando se conecta con la base de datos mediante VBA, pero quería probar todas las posibilidades, consultas de Access, conectar con DAO, conectar con ADO, intentar hacer algo parecido a PassThrough (paso a través, ¿existe para backend Access?, pronto lo veremos…).

Al final encontré una solución bastante correcta para todos los casos y tipos de pruebas:

  • Meter en una variable el valor que devuelve la función Timer (Devuelve un tipo Single que representa el número de segundos transcurridos desde la medianoche).
  • Abrir un formulario.
  • Ejecutar la consulta.
  • Asignar los valores devueltos por la consulta al origen de datos del formulario
  • Meter en otra variable el valor que devuelve la función Timer.
  • Restar las 2 variables.
  • Meter todo esto en un bucle para que haga las pruebas necesarias y hallar la media en segundos.

Algo parecido a esto:

n = txPruebas.value
For i = 0 To n

'******************************************************
    empieza = empieza + Timer
    DoCmd.OpenForm ("Lista_llena")
    'Haz lo que tengas que hacer
    Forms!pruebas.RecordSource = "Resultado"
    acaba = acaba + Timer
    
    DoCmd.Close

Next

txresult = (acaba - empieza) / n
'******************************************************

Después tenía que encontrar un escenario en el que la base de datos tuviera los suficientes registros para que las pruebas nos dieran unos resultados significativos y además que estuvieran en red (en local se podrían hacer las mismas pruebas pero los resultados no iban a ser tan interesantes ya que en red se supone que el cuello de botellas es el traslado de datos desde el servidor al equipo local, ya veremos si es verdad).

Como ya sabréis (si no os lo digo ahora), trabajo en la Administración Pública, así que dispongo de varias aplicaciones de creación propia (en Access con BackEnd Access en servidor de archivos), están en una red grande (supongo que será de las más grandes del país), tienen los suficientes registros y conozco al de sistemas para que me deje hacer pruebas a la noche y no se mosquee (muy importante). Además, aunque todo el trabajo que hago para el blog lo hago desde mi casita, las pruebas me pueden valer para optimizar las aplicaciones de mi trabajo, que nunca viene mal.

Así que en el próximo artículo sobre rendimiento de bases de datos Access os mostraré los resultados y las conclusiones que he sacado. Algunos os vais a sorprender, os vais a sorprender mucho. Probablemente es el artículo en el que más me ha costado realizar la labor de investigación previa (mirar lo que ya hay en internet, revisar la documentación de Microsoft, ingeniar una herramienta para medir rendimientos, realizar las pruebas y sacar las conclusiones), pero probablemente sea el artículo del que más orgulloso me sienta, con el que más haya aprendido y el más interesante para vosotros (o eso creo).

De momento, solo publicaré las pruebas en consultas de selección. Van a ser varios tipos de consultas, conexiones distintas a la base de datos, consultas Access, DAO, ADO, ¿PassThrough?, consultas con criterios, sin criterios, etc.

Los resultados me han sorprendido muchísimo, a lo mejor más de uno se replantea su opinión sobre Access como base de datos. De momento os describo el escenario y en el siguiente artículo pasamos a las pruebas y los resultados:

  • 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.
  • Consultas: Varios tipos. Devuelven valores entre 41 registros y 372.492 registros (si, habéis leído bien).
  • 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

Pues nada, que este es el escenario que he utilizado. Las pruebas las he realizado durante la noche para poder dejar el PC funcionando sin que mi trabajo interfiera y para no ralentizar el servidor (no creo que pasara nada con estas pruebas, pero por si acaso…). Espero que os quedéis con ganas de ver los resultados, desde luego el trabajo que me ha costado todo esto es bastante grande. Supongo que os vendrá bien a algunos.

Nota: Sí, trabajo en la Administración Pública. Sí, hay aplicaciones en Access y sí, pueden pasar las auditorías de seguridad.

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