En la empresa para la cual trabajo actualmente, hemos estado teniendo problemas de rendimiento en el servidor, y se detectó que algunos programas consumen muchos recursos, entonces comenzamos a revisar esos programas. Uno en particular se ejecutaba varias veces al día y tomaba al rededor de una hora en terminar, después de dedicarle un par de días de trabajo, ahora el programa toma solo 5 minutos y estas son las lecciones que aprendí:
¿Como se origino el problema?
Todos los programadores tenemos fechas de entrega, a veces son tan apretadas que solo nos preocupamos por entregar un programa que realice la tarea que se nos solicito, sin importar si se hicieron las pruebas necesarias o si había una mejor forma de hacer las cosas. En este caso para cumplir con el requerimiento, se hizo una copia de otro programa similar y sobre esté se agrego algo de código para dar el resultado que se pedía. Los primeros meses la solución fue aceptable ya que logro solucionar el problema inicial, pero también ocasiono los siguientes problemas:
- Consumía más ancho de banda de la necesaria. El programa se conectaba remotamente a otro sistema y trasmitía toda la información que recolectaba en una estructura de aproximadamente 30 campos y 1500 registros, los cuales el otro sistema recibía pero solo usaba al rededor de 5 campos y 300 registros ignorando el resto de los datos.
- Consumía más tiempo del servidor de bases de datos, se ejecutaban lecturas de la base de datos que no se necesitaban, y no se había verificado usas sentencias SQL alternativas para mejorar el rendimiento.
- Consumía más tiempo del servidor de aplicación, el programa procesaba información no necesaria, esto consumía más CPU del necesario.
- Consumía más memoria en el servidor de aplicación y bases de datos. Esto como consecuencia de todo lo antes mencionado.
- La suma de todo lo anterior hacia que todos los demás procesos tardarán más tiempo en ejecutarse. Debido a que este programa consumía bastantes recursos, dejaba a los demás programas esperando para poder obtener los recursos que necesitaban (CPU, memoria y ancho de banda)
¿Como se mejoro el programa?
Para corregir este problema seguí lo siguientes pasos:
- Consultar cuales eran los requerimientos del programa.
- Revisar el código para entender lo que hacia.
El siguiente paso lógico era utilizar las herramientas de análisis de ABAP para encontrar y corregir los cuellos de botella, pero en este caso al revisar los primeros dos puntos me di cuenta que el problema es que el programa realizaba una serie de tareas innecesarias, recuperaba información que no solicitada y tenia lecturas de la base de datos no optimizadas. Entonces decidí hacer un nuevo programa desde cero, considerando lo siguiente.
- Re definir todas las instrucciones de lectura de la base de datos considerando las mejores practicas.
- Limitarme a recuperar y procesar solo la información necesaria para cumplir con el objetivo, por ejemplo evitar el uso de “Select * ” y en su lugar indicar los campos que necesito.
- Hacer mediciones del programa para detectar cuellos de botella (transacción SE30).
Conclusión
Al final es más costo en tiempo y dinero, tener que corregir un programa en producción, que hacerlo bien desde la primera vez, por eso es mejor alargar un poco las fechas de entrega para poder desarrollar un mejor programa. Usualmente las pruebas que se hacen en el ambiente de calidad se limitan a verificar que el programa cumpla con su objetivo, pero para mi punto de vista, también deberían de incluir un control de calidad del código del programa.