Te ofrecemos esta traducción automática para facilitar la lectura.
En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.
Introducción a la bandeja de entrada de riesgos de rendimiento
avance
Todavía estamos trabajando en esta característica, ¡pero nos encantaría que la probaras!
Esta característica se proporciona actualmente como parte de un programa de vista previa de conformidad con nuestras políticas de prelanzamiento.
Performance Risks inbox agrega una capa inteligente sobre los telemetry data de New Relic, escaneando continuamente sus aplicaciones en busca de problemas de rendimiento y mostrándolos antes de que se conviertan en incidentes de producción. Utiliza analizadores integrados para detectar automáticamente anomalías de rendimiento mediante umbrales configurables, y agrupa los problemas similares para que pueda concentrarse en resolver primero los problemas de mayor impacto.
Cobertura y alcance
Performance Risks inbox proporciona un monitoreo integral en todo su stack de aplicaciones:
Servicios de APM
Aplicación Browser
Operaciones de base de datos
Beneficios clave
Detección proactiva de problemas: identificar problemas de rendimiento antes de que se conviertan en incidentes de producción
Tiempo medio de resolución (MTTR) reducido: la agrupación inteligente le ayuda a enfocarse primero en los problemas más críticos
Productividad de ingeniería mejorada: dedique menos tiempo a la investigación manual del rendimiento y más tiempo a la innovación
Mejor confiabilidad de la aplicación: aborde los riesgos de rendimiento antes de que afecten a sus usuarios finales
¿Cómo funciona la bandeja de entrada de riesgos de rendimiento?
Performance Risks inbox utiliza los siguientes analizadores para detectar los problemas de rendimiento más comunes:
Las consultas lentas de la base de datos suelen ser la causa principal de los problemas de rendimiento de la aplicación y pueden provocar problemas en cascada en todo su stack. El analizador identifica las consultas de la base de datos que tardan más de lo esperado en ejecutarse, lo que puede afectar significativamente los tiempos de respuesta de la aplicación y la experiencia del usuario.
Qué puede ayudar a detectar:
Consultas SQL que superan los umbrales de rendimiento
Operaciones de base de datos que pueden estar causando cuellos de botella en la aplicación
Consultas con rendimiento que se degrada con el tiempo
Las consultas N + 1 pueden aumentar exponencialmente la carga de la base de datos y los tiempos de respuesta a medida que sus datos crecen, lo que hace que este sea un problema de rendimiento crítico que debe abordarse a tiempo. Este analizador detecta el antipatrón común de consulta N + 1 donde una aplicación ejecuta N consultas en lugar de una consulta. Esto normalmente ocurre en los framework ORM al cargar datos relacionados.
Qué puede ayudar a detectar:
Consultas de base de datos repetidas en bucles
Patrones de carga de datos ineficientes
Secuencias de consultas generadas por ORM que podrían optimizarse
Las operaciones excesivas de base de datos pueden sobrecargar tus servidores de base de datos y crear cuellos de botella de rendimiento que afectan a toda tu aplicación. Este analizador monitorea las aplicaciones que realizan un número inusualmente alto de conexiones o consultas a la base de datos dentro de un período determinado, lo que indica posibles ineficiencias en los patrones de acceso a los datos.
Qué puede ayudar a detectar:
Volúmenes anormalmente altos de consultas de la base de datos
Patrones de procesamiento por lotes ineficientes
Las operaciones secuenciales de base de datos a menudo representan oportunidades de optimización desaprovechadas que pueden mejorar significativamente el rendimiento de la aplicación con cambios relativamente simples. Este analizador ayuda a identificar situaciones en las que las operaciones de la base de datos se realizan secuencialmente cuando podrían optimizarse mediante la paralelización o el procesamiento por lotes.
Qué puede ayudar a detectar:
Operaciones secuenciales de base de datos que podrían paralelizarse
Oportunidades perdidas para el procesamiento por lotes
Patrones de acceso a datos ineficientes
Las cargas HTTP grandes pueden ralentizar las transferencias de red, aumentar los costos de ancho de banda y afectar negativamente la experiencia del usuario, especialmente en dispositivos móviles o conexiones de red más lentas. Este analizador monitorea las requests y respuestas HTTP en busca de cargas que excedan los umbrales de tamaño óptimo.
Qué puede ayudar a detectar:
Requests o respuestas HTTP con cargas grandes
Extremos de API que devuelven datos excesivos
Patrones ineficientes de serialización o transferencia de datos
Las respuestas HTTP lentas pueden degradar la capacidad de respuesta de la aplicación, reducir el rendimiento y frustrar a los usuarios que esperan datos; particularmente en flujos de trabajo sensibles a la latencia o regiones con mayor sobrecarga de red. Este analizador monitorea las transacciones HTTP para detectar tiempos de respuesta que superan los umbrales de latencia óptimos, lo que puede indicar problemas de rendimiento más profundos en todo su stack.
Qué puede ayudar a detectar:
Respuestas HTTP con alta latencia
Extremos de API con tiempos de respuesta consistentemente lentos
Procesamiento de backend ineficiente, patrones de consulta o dependencias de terceros que contribuyen a las ralentizaciones
Casos de uso
Performance Risks inbox lo ayuda a abordar dos áreas clave: reducir los costos de infraestructura y mejorar el rendimiento de la aplicación. Los siguientes son ejemplos de casos de uso que ilustran cómo Performance Risks inbox puede abordar estas áreas.
Reducir los costos de infraestructura
Los patrones de código ineficientes dan como resultado un consumo innecesario de recursos que afecta directamente los costos de infraestructura:
N+1 consultas: en lugar de ejecutar una única consulta optimizada, una aplicación ejecuta una consulta para recuperar una lista y luego una consulta separada para cada elemento de esa lista. A escala, un usuario que espera a que se completen 100 consultas de la base de datos —cuando una sola consulta podría devolver el mismo resultado— aumenta innecesariamente tanto la carga de la base de datos como el uso de recursos.
Cargas HTTP grandes: cuando una aplicación llama a una API grande y envía la respuesta completa en cada interacción del usuario, los proveedores de cloud cobran por el ancho de banda y la transferencia de datos de cada llamada, incluso cuando esos datos no eran necesarios para la interacción.
Mejorar el rendimiento de la aplicación
Los problemas de rendimiento afectan directamente la velocidad y la capacidad de respuesta de la aplicación:
Consultas secuenciales de la base de datos: cuando un usuario hace requests de dos elementos de datos no relacionados, la aplicación puede recuperar el primero y esperar a que se complete antes de recuperar el segundo — aunque ambas consultas son independientes y podrían ejecutarse al mismo tiempo. El usuario espera más tiempo del necesario por un resultado que podría haberse devuelto mucho más rápido.
Respuestas HTTP lentas: cuando un usuario interactúa con la aplicación y ve un estado de carga durante un período prolongado, a menudo se debe a que una API subyacente no tiene un buen rendimiento. El usuario se ve obligado a esperar una respuesta lenta antes de que aparezca el resultado.
