EL ENVEJECIMIENTO DE LOS SISTEMAS Y LA NECESIDAD DE LA OPTIMIZACIÓN PARA SU CRECIMIENTO

Uno de los grandes errores en los sistemas a través del tiempo, es creer que éstos no envejecen; no me refiero a que envejecen como nosotros y que se hacen menos eficientes, o se vuelvan necios y por lo tanto no se pueda hablar con ellos o razonar, aunque pareciera que sí. En este caso me refiero que los sistemas que utilizan bases de datos no son estáticos, no permanecen eficientes con el paso del tiempo, ya que son susceptibles al cambio de información y a las condiciones de las mismas por la operación y crecimiento del negocio. 

Con la experiencia de los años he visto cómo los sistemas ya implementados requieren mantenimiento en su interacción con las bases de datos, derivado de que las consultas y reportes que se programaron en su etapa inicial no se mantienen eficientes por una falta de previsión para poder procesar los datos con las condiciones cambiantes de cantidad de información, combinación de los datos, concurrencia de usuarios, plataformas o sistemas adicionales que se conectan con diferentes técnicas de programación

¿Cómo se pueden presentar estos problemas?

1. Lentitud de consultas o reportes ya funcionando. En este punto nos referimos a reportes que al inicio de la vida del sistema podían ofrecer la información en segundos y con el paso del tiempo estos reportes comienzan a tardar minutos y después horas, de forma que termina siendo inútil poder utilizarlos para obtener la información y tomar decisiones

2. Pantallas que interactúan con la información y muestran todo el conjunto de datos como primera opción. Este punto se refiere a que por el diseño del sistema no se consideró que las pantallas que muestran información no llegarían a tener mucha información, por lo tanto la muestran de forma plana y sin filtrar para que la vea el usuario. Por ejemplo, la pantalla de consulta de clientes para una una empresa con 50 clientes es rápida y eficiente  pero una empresa de 50 mil clientes es una situación completamente diferente 

3. Procesos lentos que hacen que otros usuarios en red no puedan realizar el mismo proceso concurrentemente. En los sistemas que usan base de datos hablamos de procesos concurrentes, los cuales son aquellos que los usuarios pueden hacer al mismo tiempo en diferentes terminales, pero si estos datos afectan información relevante de la base de datos (por ejemplo, el saldo de un cliente) la programación del sistema debe de hacer el proceso lo más rápido posible, ya que si dos o más usuarios quieren intentan hacer la modificación al mismo tiempo los demás tienen que esperar a que el primero termine para hacer el cambio.

4. Integración de sistemas de terceros. Con este punto nos referimos a todos aquellos sistemas que no son partes del sistema original y que pueden estar utilizando la misma información de lectura, o estar escribiendo datos al mismo repositorio y que esta injerencia externa esté generando problemas a nuestro sistema original

Los problemas anteriores pueden irse presentando poco a poco en diferentes momento de la vida de los sistemas y cada uno de ellos deben analizarse para llegar a una solución adecuada, ya que muchas veces puede tomarse la decisión más rápida y probablemente incorrecta, que es aumentar los recursos de cómputo para los servidores y equipos personales. Si bien esta es una opción, no debe ser la primera ni la única, pues se puede incurrir en gastos innecesarios

¿Qué hacer cuando se nos presente en nuestras empresas esta situación?

1. Revisión del desempeño del servidor de base de datos. Todos los servidores de base de datos tienen herramientas que permiten revisar el desempeño del equipo en el cual esta ejecutándose, aquí es importante revisar que nos dice con respecto a los siguientes parámetros: memoria, espacio en disco, operaciones de entrada y salida en disco, cantidad de datos que se transfieren en red, memoria cache.

2. Revisión del desempeño de las consultas (sentencias SQL). Todos los servidores de base de datos  contienen herramientas para poder identificar las consultas que pueden esta generando problemas de lentitud, si estas consultan coinciden con las que se usan en el listado de reportes o pantallas lentas estas son las primeras en revisarse para hacerse la adaptaciones de mejora.

3. Estadísticas de crecimiento de la información. Necesitamos saber como ha crecido la información del sistema desde el punto en que se consideraba rápido y eficiente hasta el momento en que estamos  y sobre esto también hacer un mapa de cruce de información con respecto a los reportes o pantallas de las listas anteriores

4. Diagrama de flujo de datos e interacción con los módulos. Esta información básica en la arquitectura de los sistemas la debemos contraponer con los módulos lentos así como con los sistemas de terceros que se hayan incluido

Estrategias de solución

La recomendación es que el punto de inicio sea analizar el desempeño de las consultas o sentencias SQL, con las estadísticas que ofrecen los servidores de base de datos, a partir de donde podemos identificar los siguientes tipos de problemas:

1. Falta de índices. Hay que crear los índices de las tablas que forman parte de las consultas identificadas como lentas, esto ayudará al servidor de base de datos a generar un plan de ejecución más eficiente. 

2. Eliminar índices que no se utilizan. Si bien los índices son un apoyo para hacer más eficientes las consultas, los índices que no se utilizan pueden generan una sobrecarga de trabajo a los servidores al momento de actualizar la información 

3. Aplicar estrategias de optimización (Tunning) de las consultas más costosas. En muchas ocasiones esto significa escribir nuevamente la consulta de diferentes formas, para lograr obtener la misma información pero de forma más eficiente. A veces estas técnicas requieren un conocimiento avanzado SQL y de la forma en que los servidores procesan la información, por esta razón es conveniente tener a alguien que pueda hacer esta tarea en el equipo de trabajo.

4. Actualización de estadísticas de información. Los servidores de bases de datos generan estadísticas de la información actual que les permite identificar la cantidad de información y la dispersión de la misma para poder generar planes de ejecución más eficientes, pero en ocasiones estas estadísticas no se generan automáticamente o con la frecuencia necesaria para poder ayudarnos. 

En el caso de  la lentitud en la pantallas de los sistemas, es recomendable seguir estrategias como las siguientes:

1. Revisar las consultas con las estrategias anteriores.

2. Reprogramar las pantallas para que se apliquen filtros iniciales cuando el usuario las solicita, o no presentar información hasta que el usuario acote el resultado de la búsqueda a través de filtros que seleccione.

3. Paginación de la información. Es un error común no prever la cantidad de información que se presenta en una pantalla pero esta decisión puede resolver muchos problemas de desempeño general, ya que dividir la información en páginas permite hacer búsquedas parciales de la información y el tráfico de datos entre el servidor y la aplicación se reduce. 

Después de aplicar las dos estrategias anteriores, es tiempo de revisar la información estadística de uso de los recursos del servidor para determinar si es necesario el aumento de recursos. Esta opción es posterior a los análisis anteriores, ya que de hacerse como primer paso podemos incurrir en gastos no necesarios para problemas que pueden y deben resolverse desde el software.

Si todo lo anterior no da el resultado esperado, la última estrategia que recomiendo aplicar es la depuración de la información que se tiene en línea, es decir, analizar si el histórico de información que se tiene disponible para búsquedas de los usuarios es realmente necesario y determinar cuánto tiempo se requiere disponible. Este es un proceso completo de análisis en el cual tiene que participar todas las áreas de la empresa para dejar solo en línea la información histórica necesaria.

Escrito por Pablo Alberto Sánchez López

Contacto

psanchez@nextsys.com.mx