Una vez que termines con este artículo, deberías ser capaz de identificar los problemas consistentes y priorizarlos basándose en sus características.
Los problemas consistentes caen en 4 categorías diferentes. Una vez que seamos capaces de identificar estas categorías, podremos identificar y resolver de una forma más rápida los problemas consistentes. Una vez priorizados los problemas, puede asegurarse de que los problemas que afectan más al negocio, se resuelven antes.
Definición de Problema Consistente
Son los que ralentizan las aplicaciones de forma consistente.
- No son dependientes de la hora o de la carga
- No se mejoran añadiendo capacidad
- No se mejoran retocando la configuración de los servidores
- No se resuelven reiniciando el sistema
- Normalmente sólo afectan a algunas funcionalidades
Ser capaz de identificar un problema consistente te permite identificar de una forma más rápida los métodos correctos para resolver el problema.
Esencialmente, un problema de una aplicación consistentemente lenta suele provenir de la arquitectura de la aplicación o de un problema externo al servidor de aplicaciones. En este artículo vamos a explorar cómo especificar estos problemas.
Las causas potenciales de los problemas consistentes son:
- Demasiadas capas entre componentes
- Uso excesivo de un sistema externo
- Respuesta de back-end lenta
- Código ineficiente
Demasiadas capas entre componentes
Una capa es la responsable del envío de datos entre dos objetos. Cada petición se envía múltiples veces según se añaden capas nuevas.
Un ejemplo real de un cliente es una consulta SQL que se serializa en XML, mejorada mediante XSLT, leída mediante yna capa de gestión de datos y devuelta a un ENterprise JavaBeab (EJB) como un array.
Una vez que se ha identificado probables problemas consistentes, vamos a aprender a identificarlos mediante las métricas que los caracterizan. Mediante la identificación de los problemas consistentes, se pueden priorizar para que los que perjudiquen más al negocio, se resuelvan antes.
Una capa se define como el objeto que realiza el envío entre otros dos objetos necesitando comunicar uno con otro. Tener múltiples capas entre los componentes puede causar un comportamiento consistentemente lento.
Actualmente hay varios estándares sobre cómo formatear los datos. Una consulta SQL debe ser devuelta como un conjunto de registros de la base de datos empaquetados en un objeto específico de ararys, Otros datos estructurados pueden ser devueltos como texto delimitado por comas, XML o jSON. Además hay otros formatos de datos estándares como EDI X12, serialización de datos, etc. El problema de tener tantos estándares diferentes es que muchas veces un programa necesita traducir la información de un estándar a otro y luego volver al original de nuevo.
Métricas que identifican demasiadas capas entre componentes
- El tiempo de respuesta del Front-End es alto
- El tiempo de respuesta del Back-End es el habitual
- Lo tiempos de respuesta se van acumulando en cada capa
- No hay un componente individual que se dispare en tiempos
Lo que en una monitorización voy a descubrir es:
- Se incrementa el tiempo medio de respuesta de la aplicación
- Se incrementa el uso de CPU
- Se decrementa el número de threads disponibles
- Se decrementa el número de ejecuciones por intervalo de tiempo
Este conjunto de métricas muestran la firma típica de un problema de demasiadas capas en una aplicación. Así como no hay ningún componente que se dispare, va a haber una congestión de tráfico porque las peticiones se ralentizan y no son devueltas en un tiempo razonable. Las ejecuciones concurrentes del método o métodos que generan el problema se van incrementando porque se incrementa el tiempo. Asimismo, los threads se decrementan debido a esas transacciones lentas, se toman los threads del pool y no se liberan de forma rápida para que los puedan usar otros procesos.
Cómo priorizar el problema de demasiadas capas.
Un problema de demasiadas capas, es un problema de código. Dependiendo de la naturaleza del envío o de la conversión de datos, deberían existir métodos diferentes de enviar los datos de entrada y salida en diferentes formatos. Se deben explorar las alternativas por un programador o un arquitecto. Por eso, la documentación que se crea para ese problema se reenvía a los responsables del código y del diseño de la aplicación.
Uso excesivo de Sistemas Externos
Otra causa de una aplicación consistentemente lenta es un sobreuso de sistemas externos. Normalmente esto ocurre cuando el sistema backend se llama múltiples veces desde diferentes objetos.
Las causas pueden ser un mal uso de un sistema Back End o demasiadas peticiones al sistema.
Ejemplos: Usar demasiado frecuentemente el LDAP para comprobar las credenciales de los usuarios, enviar múltiples veces un email a muchos usuarios en vez de un mensaje a una lista de direcciones.
Métricas que identifican un uso excesivo de sistemas externos
- El tiempo medio de respuesta se incrementa
- El número de peticiones y respuestas a ese sistema backend se incrementa enormemente
- Los tiempos de respuesta sobre ese sistema se incrementan
- Disminuye el número de Threads disponibles
Cómo priorizar el problema de uso excesivo de sistemas externos
La documentación para la gestión de un incidente por un problema de uso excesivo de sistemas externos, se redirecciona a un programador o a un arquitecto, ya que son problemas relacionados con el código.
Respuesta lenta del Backend
En una encuesta realizada, las respuestas indican que la causa más común son los sistemas back-end, como la base de datos. Si hay una consulta que causa el problema de rendimiento, ningún cambio en el servidor de aplicaciones puede mejorar la situación. Si, sin embargo el problema se debe al código de la consulta, entonces de debe mejorar ese código.
Un ejemplo puede ser una consulta lenta ( tres transacciones por segundo) que no mejora al incrementar el tamaño del pool de conexiones.
Métricas que identifican una respuesta lenta del Backend
- Tiempo medio de respuesta de la consulta muy alto
- Se decrementan los threads del servidor de aplicaciones
- Se decrementan las conexiones disponibles del pool de conexiones
Para investigar si un sistema backend está respondiendo mal, hay que investigar los tiempos de respuesta de las consultas que se hacen a ese servidor. Los tiempos de respuesta de la base de datos serán los que más tiempo se lleven de cada transacción.
Cómo priorizar el problema de respuesta lenta de Backend
La respuesta lenta de Backend puede venir de dos “culpables”. El primero es el sistema en sí, las bases de datos pueden necesitar actualizaciones, o bug fixes para hacer que ciertas consultas funciones a la perfección. La segunda razón es un código no perfeccionado o la estrategia que se utiliza para obtener la información. En el primer caso hay que acudir al administrador del back-end para ver que lo solucione, y en el segundo al programador o al arquitecto.
