Cinco razones por las que las aplicaciones son lentas
Riverbed Technology comparte cinco causas del por qué una aplicación trabaja de forma lenta, así como consejos para detectar el problema y arreglarlo:
1. Cliente lento. Las aplicaciones web tienden a fomentar la interacción del usuario a la estación de trabajo del cliente. A partir de ahí, el código JavaScript procesa cientos o miles de filas de datos, que pueden causar pausas de varios segundos, antes de que el cliente pueda visualizar las actualizaciones.
La solución: con un sistema de administración de rendimiento de aplicaciones de alta calidad (Application Performance Management), como Opnet AppResponse Xpert, es posible identificar a los clientes con este tipo de retraso de procesamiento interno y diferenciar entre pausas en la aplicación y «tiempos de reflexión» humanos.
2. Servidor lento. Las aplicaciones modernas se despliegan en una infraestructura típica de varios niveles. Un servidor web “front-end” negocia con un servidor de aplicaciones, que a su vez negocia con un servidor middleware que consulta uno o más servidores de bases de datos. Después, todos esos servidores podrán hablar con los servidores DNS para buscar direcciones IP o asignar de nuevo los nombres de servidor. Cuando eso sucede, tan sólo un enlace débil hará que la aplicación se atrase.
La solución: se deben comprender las interacciones entre los múltiples componentes de una aplicación. Este proceso, llamado Mapeado de Dependencia de la Aplicación (Application Dependendy Mapping), utiliza información de soluciones preexistentes de monitoreo como parte de un enfoque integrado de APM. La red proporciona un panorama para ADM, lo que significa que el equipo de la redes puede ayudar a los equipos de servidor y a la aplicación. Hay que tomar en cuenta, sin embargo, que el uso de herramientas de captura de paquetes para descubrir si la red o aplicación es el culpable, podría tomar muchas horas de trabajo.
Para ahorrar tiempo, la compañía propone su solución Opnet AppResponse Xpert, que permite identificar la causa. Una vez que se establecen los puntos de control adecuados y configuraciones básicas, se proporciona un ROI fácil de usar. Además la información recabada provee la aportación que se requiere para dibujar mapas de dependencias de las aplicaciones críticas.
3.Bases de datos diminutas. Aplicaciones desarrolladas en una LAN rápida con un pequeño conjunto de datos. Una vez puestas en producción y mientras sigue creciendo la base de datos también lo hace el tiempo de inactividad.
La solución: un análisis podría mostrar que un servidor clave middleware está haciendo demasiadas solicitudes a un servidor de base de datos. (De hecho, una sola solicitud de un cliente puede resultar en muchas solicitudes de base de datos o la transferencia de un volumen significativo de información). Normalmente con hacer la consulta de bases de datos más eficiente se soluciona el problema.
4.Conversación excesiva. El problema: un servidor de aplicaciones, o tal vez el propio cliente, hará muchas solicitudes pequeñas para ejecutar una transacción a nombre de la persona que ejecuta la aplicación. Sin embargo, con la llegada de la virtualización, el equipo del servidor puede haber configurado la migración de la imagen del servidor a un servidor huésped ligeramente cargado. Esto podría mover una imagen de servidor a una ubicación que lo pone varios milisegundos más lejos de otros servidores o de su sistema de almacenamiento en disco.
La solución: es necesario tener visibilidad del número de solicitudes entre sistemas, dónde éstos se conectan a la red, y los retrasos entre solicitudes. Esto se puede automatizar también con la solución antes mencionada, que captura transacciones desde la tienda de paquetes, ello permite predecir el cambio en los tiempos de respuesta dados en los diferentes parámetros de red como latencia, ancho de banda, y pérdida de velocidad.
5. Servicios de red lentos. El problema: pueden disminuir el rendimiento de una aplicación, ello no implica que sea la propia red, pero sí los servicios en que se basan la mayoría de las aplicaciones que dependen de una red. Considere una aplicación que realice consultas a un servidor DNS primario inexistente. Al no recibir respuesta, la aplicación debe rechazar la primera solicitud antes de intentar consultar al segundo servidor DNS. En esa situación la aplicación disminuye periódicamente, pero el resto del tiempo funciona muy bien.
La solución: La herramienta de la marca ofrece observar y registrar las transacciones todo el tiempo. Identifica cuando hay una lenta ejecución y busca la raíz de la causa de la información.
