Rendimiento MAINFRAME, Factor clave en la economía digital

Home / Blog / Rendimiento MAINFRAME, Factor clave en la economía digital

El otro día me preguntaron si el rendimiento Mainframe era importante, respondí que ¡claro que sí!, pero una afirmación no es suficiente para convencer a nadie.

Fernando-Ortuño-OrtinArtículo de Fernando Ortuño Ortín.
Profesor Asociado en la Universidad de Alicante. 
30 años de experiencia como Director de Arquitectura, Sistemas y Seguridad en Sistemas Mainframe.

 

 

Trataré, pues, de explicar la importancia de la optimización de los sistemas, y no solo el Rendimiento Mainframe de los grandes sistemas, tales como IBM, Teradatas, etc., sino también la de los pequeños, incluidos los PCs.

En un ámbito cotidiano, si alguien le hiciese la siguiente pregunta:

¿Es importante optimizar el uso de la gasolina en los vehículos?

Seguro que su respuesta sería obvia: pues claro, hay que recorrer cuantos más kilómetros con menos combustible, o sea, hacer más con la misma energía. En los sistemas ocurre lo mismo, hay que conseguir que los programas consuman el mínimo de recursos (memoria, disco, CPU, etc.) para hacer sus tareas, pero ¿por qué no sucede así?

En las fases de un proyecto clásico: análisis, diseño, desarrollo, implantación, puesta en marcha y mantenimiento, rara vez se incluye un apartado sobre rendimiento de las aplicaciones (programas, transacciones, batch, etc.) como una mejora continuada del sistema.

Podemos hacer pruebas de estrés antes de arrancar nuestros programas, pero estas son válidas para ese software en un tiempo puntual; sin embargo, la experiencia nos enseña que el sistema va a cambiar (y muchas veces muy rápidamente), y estas pruebas ya no nos podrán confirmar que nuestro sistema esté listo para dar una respuesta satisfactoria. Esto mismo es aplicable a otras metodologías tales como XP Extreme Programming, Scrum, DSDM, etc.

La mejora de rendimiento Mainframe y de otros sistemas, no solo nos va a permitir dar una respuesta adecuada, sino que la mayoría de las veces nos permitirá ahorrar dinero.

Un dinero real, pues se evitará o se pospondrá la necesidad de compra nuevo hardware y/o las actualizaciones de software por estar instalado en máquinas más potentes, y máxime en esta época donde se suele facturar «on demand».

 

¿Cómo realizar un rendimiento de sistemas?

Cuando un programa es comprensible, se puede valorar su performance, en cambio un programa con flujo lioso es difícil de comprender y mantener, inhibiendo en la mayoría de los casos la optimización de su código; por tanto, la calidad y metodologías son necesarias para un resultado final de nuestro software.

Las áreas que afectan al rendimiento de un programa son varias:

  • Técnicas de codificación, que incluyen utilizar un estilo de programación adecuado.
  • Elección del tipo de datos.
  • Manejo de las tablas de una forma eficiente.
  • Opciones del compilador.

Las tareas se pueden llevar a cabo de una manera preventiva o cuando los sistemas tienen un problema; mi experiencia me confirma que hay que realizarlas regularmente, pero con las siguientes premisas:

  • Tener claro lo que se quiere optimizar. No hay que caer en el error de optimizar tanto el sistema que sean más costosos los esfuerzos en rendimiento que la mejora obtenida. Dicho de otra forma, hay que atender el ROI de cada mejora.
  • Los objetivos deben ser cuantificables, como:
  • El porcentaje de reducción de ocupación en disco (por ejemplo, de 4 a 8 TB).
  • Una reducción de consumo de CPU (equivalente a 4 procesadores).
  • Número mínimo de transacciones que hay que mejorar durante un periodo de tiempo.
  • Porcentaje de reducción del consumo conjunto de las transacciones.
  • Dedicar un tiempo finito durante el año, por ejemplo, tres meses, esto va en relación con el punto anterior.
  • Poner el mejor personal y con más experiencia para esta tarea, si no lo tenemos contratarlo a una empresa externa, pero verificar que tenga experiencia real en rendimiento. Esto que parece obvio, si no se tiene en cuenta, puede conllevar una pérdida de tiempo y dinero; el perfil del personal de rendimiento es bastante técnico y cualificado.

 

¿Dónde centrarse en los sistemas?

Antes de empezar con la optimización, es necesario tener datos estadísticos, pues, sin ellos, todo serán conjeturas o sensaciones finales de los usuarios. El dato debe ser «frío», es decir, indicar qué valor tenía al principio y qué valor se ha conseguido en la optimización.

En los grandes sistemas IBM e UNIX —que es donde personalmente tengo experiencia—, se pueden mejorar dos aspectos: sistemas y programas de desarrollo.

Mejoras en batch

Los datos se medirán antes de realizar las mejoras y después de las mismas; igualmente, podrán medirse trimestralmente (o con cualquier otra frecuencia) todas las mejoras, para verificar que su solución no haya empeorado.

Batch Mainframe

Batch Mainframe

 

Base de datos

En este punto es donde se puede optimizar más, pues muchas veces los desarrolladores desconocen el modelo de datos y la forma óptima de acceder a las distintas tablas. Usar adecuadamente las queries . Cuántas veces se ve <select *>.

Hay que ver si los índices son los adecuados y si se accede a través de ellos, igualmente si el particionado de las tablas es el correcto.

El coste DB2 (IBM) se debe principalmente a:

  • El número de filas y de índices escaneados por el DB2.
  • El número de filas reordenadas (sort) por el DB2.
  • El número de I/O’s.

Existe un desconocimiento de las herramientas de base de datos, por ejemplo, en IBM: EXPLAIN, APPTUNE, STROBE, DB2 Performance Monitoring, etc.

Transacciones

La selección de transacciones se debería basar en el enfoque 80/20: un reducido número de transacciones/procesos se ejecutan un mayor número de veces provocando el mayor consumo de recursos del sistema. Por lo tanto hay que determinar los tiempos y consumos de las transacciones y definir los valores que se quieren obtener.

En resumen

La optimización de los sistemas nos servirá para asegurar que el sistema puede funcionar y ser operado en producción de acuerdo con las capacidades on-line, modelo batch y los diferentes subsistemas.

Nos servirá también para verificar el correcto funcionamiento de las aplicaciones en términos de tiempo de respuesta, consumo, fiabilidad y estabilidad.

Y la configuración de software de base (este gran desconocido de las empresas) se adecuará a los requerimientos de los aplicativos.

Todo lo anterior nos proporcionará información para saber hasta cuándo nos van a servir nuestros hardware y software de base, y podremos hacer un plan adecuado de inversión para el futuro.

Para acabar, y como dije al principio, invertir en rendimiento supone un ahorro real a la empresa. Sirva como ejemplo uno de los proyectos donde trabajé, en el cual los ahorros fueron cuantiosos y el ROI se recuperó en unos pocos meses.

 

Caso real en una empresa sobre Acumulado de Mejoras y Ponderación Anual.

Se muestran los Resultados de las mejoras durante 3 años implantadas por el equipo de rendimiento, en coordinación con las áreas de Sistemas. Los Ahorros presentados son recurrentes año tras año, es decir que se van repitiendo sin necesidad de una nueva inversión.

 

Los ahorros por EXCP’s se han calculado: 1millón de EXCP’s = 44 segundos de CPU

Los ahorros por EXCP’s se han calculado: 1millón de EXCP’s = 44 segundos de CPU

 

rendimiento-mainframe-elapsed

La reducción de elapsed time produce mejoras indirectas por la reducción de la ventana batch y la reducción de esperas por iniciadores.

 

La ponderación anual se realiza extrapolando la mejora de un día al total de ejecuciones del proceso en un año: 255 veces si es diario, 12 veces si es mensual y 1 vez si es anual.

La ponderación anual se realiza extrapolando la mejora de un día al total de ejecuciones del proceso en un año: 255 veces si es diario, 12 veces si es mensual y 1 vez si es anual.

 

Related Posts
Comments
  • Avatar
    Raúl Prieto Conde

    Muy interesante Fernando, espero que nuestra herramienta os ayudara en su día a aplanar esos picos y reducir gastos en consumo CPU..y en factura.

    Un abrazo.

Leave a Comment

Límite de tiempo se agote. Por favor, recargar el CAPTCHA por favor.

Computing Spain InterviewOrizon