Advertisement
  1. Code
  2. Performance

Solución de problemas de rendimiento con Raygun

by
Read Time:8 minsLanguages:
This post is part of a series called Raygun Tools for Performance and Error Monitoring.
Raygun Real User Monitoring: Know Your Users' Experience
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Spanish (Español) translation by Marwa Shuwain (you can also view the original English article)

El desarrollo de aplicaciones web es difícil. No hay otro tipo de aplicaciones que estén tan involucradas, o requieren que tú entiendas varios idiomas, marcos, y plataformas, como las aplicaciones web. La aplicación web más básica está compuesta por dos aplicaciones independientes:

  1. La aplicación del servidor para gestionar los datos.
  2. La aplicación del cliente muestra esos datos al usuario.

La aplicación más sencilla está escrita en dos lenguajes : Uno para el servidor y HTML para el cliente. Pero eso no es todo: Las aplicaciones modernas requieren tu entiendas muchos lenguajes, marcos y herramientas de desarrollo. En el mejor de los casos, una aplicación es desarrollada por varios equipos que pueden centrarse individualmente en piezas más pequeñas de todo el conjunto. En el peor de los casos, un equipo tan pequeño como una persona desarrolla toda la aplicación.

Pero la historia no termina cuando la aplicación está "finalizada" . Después de un largo e  procesos de desarrollo largos y directamente relacionados, hay incontables horas de pruebas para detectar errores, problemas de seguridad, integración, rendimiento y experiencia del usuario. Aunque muchos desarrolladores no lo admiten, el rendimiento y la experiencia del usuario suelen pasarse por alto. El resultado, por supuesto, es que las aplicaciones lentas y sin refinar pasan a la producción.

Es precisamente por eso que existen herramientas como la supervisión del rendimiento de aplicaciones (APM) y la supervisión de usuarios reales (RUM) de Raygun. Proporcionan a los desarrolladores los medios para analizar rápidamente no solo cómo funciona su aplicación en producción, sino que también señala los problemas de rendimiento exactos al método o consulta de base de datos, así como visualizar las experiencias de sus visitantes.

En este artículo, te guiaré a través de mi experiencia usando el APM y el RUM de Raygun para señalar los problemas en un sitio web en vivo y en producción y los pasos que di para arreglarlos.

El problema: Una aplicación heredada con un código base complejo

Trabajo en un entorno de ritmo rápido donde la cantidad es más importante que la calidad. Eso no quiere decir que el software que yo o mis compañeros de trabajo escriban sea insuficiente; nuestras aplicaciones funcionan bien. Pero la demanda de nuestro tiempo nos exige centrarnos más en los errores y la seguridad que en el rendimiento y la experiencia del usuario.

Recientemente usé APM y RUM de Raygun para monitorear nuestra principal aplicación pública en la web: Un sitio web informativo para los inversionistas de la compañía. Está escrito en C# y se ejecuta en el tiempo de ejecución de .NET 4.6.x.

Esta aplicación comenzó como múltiples proyectos pequeños escritos por un equipo de tres personas con una comunicación mínima. Los proyectos compartieron una biblioteca "central" que rápidamente creció en un enorme e incontrolable bestia con mucha funcionalidad duplicada (como dije, no había mucha comunicación).

A lo largo de los años, los múltiples proyectos se transformaron en una sola aplicación grande. Extrae información de varias bases de datos MSSQL y una máquina IBM DB2 para proporcionar a los visitantes una amplia gama de información económica e industrial. Interactúa con otros sistemas de la red, desde servidores de correo y archivos y otros servicios de la API RESTful para realizar otras tareas.

También debo mencionar que soy algo único en que tengo una gran experiencia en IT. Mi puesto es “Programador/Analista”, pero mis tareas consisten en administración de redes y sistemas, programador y analista. Así que cuando se trata de analizar cualquier problema, estoy equipado para examinar tanto el código como los sistemas con los que se ejecuta e interactúa.

Identificación de problemas de rendimiento

Sé que mi aplicación tiene varios problemas de rendimiento; uno de ellos es la experiencia de autenticación. Los visitantes deben autenticarse primero con sus credenciales y luego proporcionar su OTP (contraseña única) para la autenticación de dos factores. Algunos visitantes utilizan una aplicación de autenticación independiente en su dispositivo móvil para generar sus OTPs, pero la mayoría de los visitantes reciben su código por correo electrónico. Para este último grupo, la experiencia de autenticación puede tardar entre 1 y 30 segundos, con la mayoría de los visitantes que experimentan esperas más largas.

Después de instalar y configurar el agente APM de Raygun (un proceso muy sencillo), comencé a ver los datos de rastreo en el panel de control en un minuto. El panel de control le ofrece una visión general de los problemas de rendimiento de la aplicación, proporcionando tablas y gráficos que muestran las solicitudes más lentas, los métodos de clase, los rastreos, los comandos SQL y las llamadas a la API externa. Sin duda, algunos de los infractores inmediatos estaban relacionados con el proceso de autenticación.

Dos primeros URLs lentos son usados durante el proceso de autenticación para invitados con OTPs enviado por correo electrónico . Ambos son preocupantes (¡Por Dios! 31 segundos para una solicitud de /resend2fa). Sin duda quiero solucionar todos los problemas, pero mi tiempo es limitado. Por lo tanto, solucionar algunos de los problemas con el punto final /login es mi prioridad.

A juzgar por los datos proporcionados por la tabla de "solicitudes más lentas", ya sospecho que el culpable está relacionado con el proceso de envío de correos electrónicos. Para estar seguro, hago clic en el enlace /login para ver los datos que APM recopiló en esa URL.

Análisis de los datos

APM recopila mucha información para cada solicitud y es extremadamente útil porque puede desglosar una solicitud en sus partes más pequeñas, los métodos que se ejecutan para proporcionar al visitante una respuesta. La siguiente captura de pantalla muestra los métodos, clasificados del más lento al más rápido, para la URL /login:

Como era de esperar, el problema principal tiene algo que ver con el proceso de correo electrónico. También es interesante que el proveedor IBM DB2 ADO.NET se utilice durante la autenticación. No debería ser, y está tomando una cantidad de tiempo bastante significativa para borrar la información de error como se indica por la llamada a IBM.Data.DB2.iSeries.MPConnection.clearErrorInfo() que ni siquiera debería estar allí. Pero eso es un problema para otro día.

Además de las notificaciones diarias, todos los correos electrónicos enviados por el sitio web se envían bajo demanda. El código que envía estos correos electrónicos se utiliza en una variedad de otras aplicaciones que no presentan problemas de rendimiento. Así que en mi mente, ni el código ni el servidor de correo electrónico son culpables, hay algo malo en la máquina que ejecuta nuestro sitio público .

Hay tantas cosas en un sistema informático que pueden causar problemas de rendimiento. Así que, después de ver los registros y no ver ninguna causa aparente, me decidí a hacer girar una nueva máquina virtual y probar el sitio web en ella. Después de instalar el agente APM en la nueva máquina y probar el proceso de inicio de sesión, observo una mejora tremenda.

La captura de pantalla anterior muestra el desglose de dónde llama la aplicación al método SendMessage(). Simplemente transfiriendo la aplicación a otra máquina redujo el proceso de inicio ¡en 26 segundos!. Aunque eso es sin duda una gran mejora, todavía toma un promedio de 4-5 segundos para el proceso inicial de inicio de sesión.

Examinando el flamechart para una sola solicitud /login (mostrada abajo), puedo ver claramente que enviar un correo electrónico sigue siendo un problema porque SendMessage() todavía tarda al menos 3 segundos en ejecutarse completamente.

Puedo resolver este problema enviando el mensaje de correo electrónico a una cola o lote y dejar que un proceso independiente envíe el mensaje. me parece una solución alterna . Prefiero encontrar y solucionar el problema, pero también necesito gestionar mi tiempo. Hay otros proyectos, posiblemente más importantes que necesito completar.

Análisis de la experiencia del usuario

El APM de Raygun le proporciona datos de rendimiento claros para su servidor, pero eso es solo la mitad de su aplicación. Lo que sucede en el navegador es tan importante como lo que sucede en el servidor, y la supervisión de usuario real (RUM) de Raygun le ofrece información sobre cómo los usuarios experimentan su aplicación. No solo puede realizar un seguimiento de las sesiones individuales de los usuarios y proporcionar estadísticas de uso (como el número de visitas a páginas, duraciones y exploradores), sino que también puede proporcionar una imagen precisa de su experiencia mientras navegan de página en página.

RUM también muestra cada página solicitada y divide el tiempo de carga en diferentes factores, como se muestra a continuación:

La URL /cico en esta captura de pantalla tiene un tiempo de servidor bastante alto de 5 segundos, lo que es comprensible porque esa página calcula una gran cantidad de datos recopilados de múltiples fuentes sobre la marcha. Pero ahora que veo que trabajar con datos en vivo ralentiza enormemente la carga de la página, necesito implementar una solución de almacenamiento en caché/resumen.

Observe que la URL /takepay tiene un tiempo de servidor bastante pequeño (funciona con datos en caché/resumidos), pero tiene un tiempo de procesamiento grande debido a la representación de gráficos interactivos con muchos puntos de datos. Así que, puedo resolver fácilmente la respuesta lenta del servidor para /cico almacenando en caché diariamente o resumiendo los datos con los que trabaja en un proceso separado.

Pero el rendimiento y la experiencia de un usuario son mucho más que los tiempos de respuesta; cuando se configura correctamente, RUM cataloga todas las solicitudes, incluyendo XHR, como se muestra a continuación:

Lo primero que me llamó la atención fueron las las más de 30 solicitudes de la URL /settings/email-alerts. Más de 30 personas vieron o cambiaron la configuración de las alertas por correo electrónico, o que XHR se ejecuta automáticamente en una de las páginas. Desafortunadamente, RUM no me dio una idea inmediata de qué página hizo el XHR, pero finalmente encontré los culpables al ver los informes de rendimiento de varias páginas:

Esos XHRS innecesarios contribuyen al tiempo de carga, y su eliminación puede hacer una gran diferencia.

La conclusión

Raygun ofrece un servicio invaluable. Como muestra mi experiencia, al utilizar APM y Supervisión de usuarios reales, puedes supervisar fácilmente el rendimiento de su aplicación.

Señalan automáticamente los problemas de rendimiento tanto en el servidor como en el cliente, lo que es vital en un entorno de ritmo rápido. Son realmente servicios fantásticos  ¡y puedes probarlos gratis hoy!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.