Una vez que termines con este art\u00edculo, deber\u00edas ser capaz de identificar los problemas consistentes y priorizarlos bas\u00e1ndose en sus caracter\u00edsticas.<\/p>\n
Los problemas consistentes caen en 4 categor\u00edas diferentes. Una vez que seamos capaces de identificar estas categor\u00edas, podremos identificar y resolver de una forma m\u00e1s r\u00e1pida los problemas consistentes. Una vez priorizados los problemas, puede asegurarse de que los problemas que afectan m\u00e1s al negocio, se resuelven antes.<\/p>\n
Son los que ralentizan las aplicaciones de forma consistente.<\/p>\n
Ser capaz de identificar un problema consistente te permite identificar de una forma m\u00e1s r\u00e1pida los m\u00e9todos correctos para resolver el problema.<\/p>\n
Esencialmente, un problema de una aplicaci\u00f3n consistentemente lenta suele provenir de la arquitectura de la aplicaci\u00f3n o de un problema externo al servidor de aplicaciones. En este art\u00edculo vamos a explorar c\u00f3mo especificar estos problemas.<\/p>\n
Las causas potenciales de los problemas consistentes son:<\/p>\n
Una capa es la responsable del env\u00edo de datos entre dos objetos. Cada petici\u00f3n se env\u00eda m\u00faltiples veces seg\u00fan se a\u00f1aden capas nuevas.<\/p>\n
Un ejemplo real de un cliente es una consulta SQL que se serializa en XML, mejorada mediante XSLT, le\u00edda mediante yna capa de gesti\u00f3n de datos y devuelta a un ENterprise JavaBeab (EJB) como un array.<\/p>\n
Una vez que se ha identificado probables problemas consistentes, vamos a aprender a identificarlos mediante las m\u00e9tricas que los caracterizan. Mediante la identificaci\u00f3n de los problemas consistentes, se pueden priorizar para que los que perjudiquen m\u00e1s al negocio, se resuelvan antes.<\/p>\n
Una capa se define como el objeto que realiza el env\u00edo entre otros dos objetos necesitando comunicar uno con otro. Tener m\u00faltiples capas entre los componentes puede causar un comportamiento consistentemente lento.<\/p>\n
Actualmente hay varios est\u00e1ndares sobre c\u00f3mo formatear los datos. Una consulta SQL debe ser devuelta como un conjunto de registros de la base de datos empaquetados en un objeto espec\u00edfico de ararys, Otros datos estructurados pueden ser devueltos como texto delimitado por comas, XML o jSON. Adem\u00e1s hay otros formatos de datos est\u00e1ndares como EDI X12, serializaci\u00f3n de datos, etc. El problema de tener tantos est\u00e1ndares diferentes es que muchas veces un programa necesita traducir la informaci\u00f3n de un est\u00e1ndar a otro y luego volver al original de nuevo.<\/p>\n
La documentaci\u00f3n para la gesti\u00f3n 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\u00f3digo.<\/p>\n
En una encuesta realizada, las respuestas indican que la causa m\u00e1s com\u00fan son los sistemas back-end, como la base de datos. Si hay una consulta que causa el problema de rendimiento, ning\u00fan cambio en el servidor de aplicaciones puede mejorar la situaci\u00f3n. Si, sin embargo el problema se debe al c\u00f3digo de la consulta, entonces de debe mejorar ese c\u00f3digo.<\/p>\n
Un ejemplo puede ser una consulta lenta ( tres transacciones por segundo) que no mejora al incrementar el tama\u00f1o del pool de conexiones.<\/p>\n
Para investigar si un sistema backend est\u00e1 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\u00e1n los que m\u00e1s tiempo se lleven de cada transacci\u00f3n.<\/p>\n