Análisis de rendimiento de software

El perfilado de funciones es limitado cuando el programa contiene funciones extensas que ocupan la mayor parte del tiempo de ejecución. En estos casos, los perfiladores basados en líneas de código, como OProfile, son más útiles. Estos perfiladores requieren que los binarios tengan símbolos de depuración y se ejecuta un Daemon para recopilar datos de todos los binarios activos. Podemos extraer información de un binario específico en cualquier momento, mostrando las líneas de código con el número de muestreos y su porcentaje relativo. Sin embargo, debemos tener precaución con estos datos, ya que requieren coherencia en las tablas de símbolos generadas por el compilador para que coincidan correctamente con las instrucciones de la máquina en la memoria. El perfilado basado en líneas de código nos ayuda a identificar los puntos críticos de un programa llaman demasiadas veces. Al corregir estos problemas de diseño, se pueden mejorar significativamente el rendimiento del programa. Es importante tener en cuenta que el perfilado basado en líneas puede ser una técnica detallada y que requiere mucho tiempo y recursos.

El perfilado basado en líneas es una técnica de análisis de rendimiento de programas de computadora que consiste en medir el tiempo de ejecución de cada línea de código individualmente. Para hacer esto, se utilizan herramientas de perfilado que generan un informe detallado que muestra cuánto tiempo se tarda en ejecutar cada línea de código en el programa. Esta técnica es útil porque permite a los desarrolladores identificar las líneas de código específicas que están causando cuellos de botella o problemas de rendimiento en el programa. Al analizar el informe generado por el perfilado basado en líneas, los desarrolladores pueden ver claramente las líneas de código que están consumiendo la mayor cantidad de tiempo de CPU y, por lo tanto, son los principales contribuyentes a los problemas de rendimiento. Además, el perfilado basado en líneas puede ayudar a los desarrolladores a identificar problemas específicos de diseño de código, como bucles anidados innecesarios, operaciones costosas o funciones que se

• Trabajar menos, es decir, reorganizar el código para realizar menos trabajo siempre que sea posible.
• Evitar operaciones costosas, como las funciones trigonométricas o la exponenciación, y buscar alternativas más baratas. También es importante reducir el conjunto de trabajo del código, es decir, la cantidad de memoria que usa, para aumentar la probabilidad de aciertos en la memoria caché.
• Eliminación de subexpresiones comunes es una técnica que busca ahorrar tiempo pre calculando partes de expresiones complejas y asignándolas a variables temporales antes de que comience una construcción de código que usa esas partes varias veces. En el caso de bucles, esta optimización también se denomina bucle de movimiento de código invariable.
• Evitar ramas es otra técnica para mejorar el rendimiento. Los bucles "estrechos", es decir, los bucles que tienen pocas operaciones son candidatos típicos para canalización de software, desarrollo de bucles y otras técnicas de optimización. Si por alguna razón la optimización del compilador falla o es ineficiente, el rendimiento se verá afectado. Esto puede suceder fácilmente si el cuerpo del bucle contiene ramas condicionales.

Una de las herramientas de perfilado más utilizada es gprof del paquete GNU binutils. Gprof usa la instrumentación de código y el muestreo para recoger un perfil funcional plano, así como un perfil de llamadas, también llamado gráfico de mariposa. Para poder perfilar, es necesario compilar nuestro código con ciertas instrucciones específicas (Para el compilador GCC existe -pg) y ejecutarlo una vez. Todo este proceso genera un archivo ilegible para nosotros con nombre ‘gmon.out’, este archivo será leído e interpretado por el propio gprof. El perfil plano obtenido contiene información acerca de los tiempos de ejecución de todas las funciones y la frecuencia con la que son llamadas.

Siendo los perfiladores más populares, estos nos ayudan a poder realizar el análisis de toda la información recopilada sobre la ejecución y funcionamiento de un programa, como el tiempo de ejecución del programa o la cantidad de recursos utilizados para su funcionamiento; esto también aplica para partes específicas del programa (ej. las funciones del programa o sus variables utilizadas). Gracias a estos perfiladores, obtendremos un análisis detallado del rendimiento del código del programa, lo cual nos permitirá poder optimizarlo y tomar las medidas necesarias para mejorar su desempeño o de identificar errores de rendimiento en caso de necesitarlo.

Existen herramientas de profiling que nos permiten analizar software en tiempo real, compilando los datos relevantes de rendimiento al mismo tiempo que el programa es ejectuado, dándonos un desglose de la información que permite identificar los posibles errores de este, facilitando la solución de problemas para el desarrollador.

Gracias al avance de la tecnología en la actualidad, los profilers de la nube son una realidad y estos funcionan justo como un perfilador común, la diferencia es que estos están orientados específicamente al análisis de aplicaciones y software que se ejecute en la nube. Brindando ya no solo un análisis de programas, también un análisis orientado a la red y servidores que alojen estos programas.

Los lenguajes de programación que se listan a continuación poseen un profiler basado en eventos:

• Java (lenguaje de programación) (Java Virtual Machine Tools Interface)
• Microsoft .NET
• Python
• Ruby

Algunos profilers operan por muestreo. un profiler por muestreo prueba el "Program counter" del programa objetivo a intervalos regulares usando interrupciones del sistema operativo. Los profilers de muestreo son típicamente menos exactos numéricamente y específicos, pero permiten que el programa de destino funcione cerca de la velocidad máxima.

Algunos profilers "instrumentan" el programa objetivo con instrucciones adicionales para recopilar la información necesaria.

Instrumentar el programa puede causar cambios en el rendimiento del programa, que pueden causar resultados inexactos y heisenbugs. Instrumentar siempre tendrá algún impacto en la ejecución del programa, por lo general siempre es más lento. Sin embargo, la instrumentación puede ser muy específica y ser controlada cuidadosamente para tener un impacto mínimo. El impacto sobre un programa en particular depende de la colocación de puntos de instrumentación y el mecanismo que se utiliza para capturar la traza. El soporte de hardware para capturar la traza significa que en algunos objetivos, la instrumentación puede tener sólo una instrucción de máquina. El impacto de la instrumentación a menudo se puede deducir (es decir, eliminada por sustracción) a partir de los resultados.

gprof es un ejemplo de un profiler que utiliza tanto la instrumentación y el muestreo. La instrumentación se utiliza para recopilar información de las llamadas y los valores de tiempo real se obtienen mediante muestreo estadístico.

Esta técnica añade efectivamente instrucciones al programa de destino para recopilar la información requerida.

El efecto dependerá de qué información se está recopilando, del nivel de detalles de tiempo notificados y de si se utiliza la generación de perfiles de bloques básicos junto con la instrumentación.

La instrumentación es clave para determinar el nivel de control y la cantidad de resolución de tiempo disponible para los profilers. A continuación se enumeran todas las categorías:

• Manual:

    Realizado por el programador, por ejemplo, añadiendo instrucciones para calcular explícitamente los tiempos de ejecución, simplemente cuente eventos o llamadas a API de 
    medición, como el estándar de medición de respuesta a aplicaciones.

• Automática a nivel de código:

    Instrumentación agregada al código fuente por una herramienta automática según una directiva de instrumentación.

• Asistida por el compilador
• Translación binaria:

    La herramienta agrega instrumentación a un ejecutable compilado.

• Instrumentación en tiempo de ejecución:

    Directamente antes de la ejecución se instrumenta el código. La ejecución del programa está totalmente supervisada y controlada por la herramienta.

• Inyección en tiempo de ejecución:

    Más ligera que la instrumentación en tiempo de ejecución. El código se modifica en tiempo de ejecución para tener saltos a funciones auxiliares.

Las opciones del intérprete de depuración permiten habilitar la recopilación de métricas de rendimiento cuando el intérprete se encuentra con cada declaración de destino. Los bytecodes, tablas de control e intérpretes JIT son tres ejemplos que suelen tener un control completo sobre la ejecución del código de destino, lo que permite la oportunidad de recolectar datos muy completos.

• Hipervisor: Los datos se recogen mediante la ejecución del programa (por lo general) no modificada bajo un hipervisor. Por ejemplo SIMMON.
• Simulador y Hipervisor: Los datos son recogidos de forma interactiva y selectiva mediante la ejecución del programa sin modificar en el marco de un simulador de conjunto de instrucciones. Por ejemplo IBM OLIVER y SIMON

• Jprofiler

Es la herramienta más popular usada en aplicaciones estándar y empresariales ya que cuenta con una interfaz de usuario muy intuitiva, las características principales son el perfilamiento de hilos, encontrar fugas de memoria y resolver cuellos de botella. Es compatible con plataformas Windows, MacOs, Linux, FreeBSD, Solaris, AIX y HP-UX.

• YourKit

Esta herramienta se utiliza para analizar el rendimiento de aplicaciones java en desarrollo y producción, cuenta con funciones básicas para visualizar hilos, recolecciones de basura, uso de memoria y fugas de memoria, con soporte para perfiles locales y remotos. También es útil para la creación de perfiles de CPU, que permiten la creación de perfiles enfocados en ciertas áreas de nuestro código, análisis de E/S y de multithreading. Es compatible con plataformas Windows, MacOs, lINUX, etc.

• Java VisualVM

A diferencia de las anteriores, esta herramienta es gratuita y esta incluida en el Java Developer Kit: (JDK), Java VisualVM proporciona un conjunto de herramientas de análisis de rendimiento que incluyen monitoreo de memoria, análisis de CPU, análisis de hilos y un profiler de java.

• NetBeans Profiler

Se incluye con el Netbeans IDE de código abierto de Oracle y es una buena opción cuando queremos que todo éste incluido en un solo programa (IDE+Profiler), es mayormente conocido por su debugger, pero el IDE incluye un perfilador ligero que permite monitorear el CPU y tiempo de ejecución.

• IntelliJ Profiler

Esta herramienta es útil para la creación de perfiles de asignación de CPU y memoria, nos permite comenzar con unos pocos clics sin ningún tipo de configuración, además de que nos permite evaluar visualmente el rendimiento de diferentes enfoques y obtener información sobre las operaciones en tiempo de ejecución de manera rápida y eficiente.

• Gproof

Es una herramienta de análisis de rendimiento que produce un perfil de ejecución de programas en C, Pascal o FORTRAN77, Gprof calcula la cantidad de tiempo empleado en cada rutina.  Después, estos tiempos se propagan a lo largo de los vértices del grafo de llamadas.

• Intel VTune Profiler

Es una herramienta de análisis de rendimiento para plataformas x86 y x64 que proporciona una amplia variedad de información sobre el rendimiento del sistema, es de libre uso y con perfilamiento de memoria, CPU y análisis de almacenamiento en procesadores Intel.

• oTools

Desde Mac nos permite traducir a lenguaje ensamblador el código de C.

• Perf

Es una herramienta de perfilado de rendimiento de sistema en Linux que se utiliza para analizar la utilización de la CPU y la memoria, y para medir el rendimiento de aplicaciones.

• Valgrind

Es una herramienta de depuración y perfilado de memoria que ayuda a detectar problemas de memoria, como fugas de memoria y errores de acceso.

• cProfile Viene incluido en la biblioteca estándar de python, éste rastrea el llamado de las funciones dentro del programa y genera una lista con las funciones que más tiempo tardan. Tiene tres puntos fuertes que son:

1. Que se incluye con la biblioteca estándar.
2. Que perfila una serie de estadísticas diferentes sobre el comportamiento de las llamadas, esto permite determinar si una función es lenta por sí misma o si llama a otras funciones que son lentas.
3. Que puede restringir cProfile libremente, es decir, mostrar toda la ejecución de un programa o activar la creación de perfiles solo cuando se ejecuta la función seleccionada.

• FunctionTrace

Simular a la herramienta anterior genera reportes de las funciones llamadas y la memoria usada por el programa en ejecución guardándolo en un JSON con posibilidad de usar el Firefox Profiler.

• Line Profiler

Es una herramienta de perfilado que nos permite medir el tiempo de ejecución de cada línea de código en las funciones, además esta herramienta nos permite detectar los cuellos de botella de rendimiento y optimizar el código para mejorar el rendimiento.

• PyInstrument

Similar a cProfile pero este nos brinda un informe de aquella parte del código que toma más tiempo, las principales diferencias son 2:

1. Que muestrea la pila de llamadas del programa cada milisegundo, con lo que podemos detectar lo que está consumiendo la mayor parte del tiempo de ejecución.
2. Que nos da informes más concisos, pues nos muestra las funciones principales del programa que consumen más tiempo.

• Pyflame

Es una herramienta de perfilado que nos permite medir el tiempo de ejecución de cada función en el código de python. Es una herramienta de bajo impacto que no afecta significativamente el rendimiento de la aplicación.

Podemos observar que existen múltiples herramientas de perfilado y la elección del perfilador adecuado depende de las herramientas utilizadas, el nivel de análisis requerido y las características específicas del profiler, es por lo cual, es necesario considerar los requisitos de nuestro proyecto y la información específica que busquemos obtener, para después elegir él perfilador que más se adapte a nuestras necesidades. Por otro lado, otra de las consideraciones principales al elegir un profiler es que se deben considerar las tecnologías de perfilado, de las cuales se hablarán a continuación.

Utilizar el rastreo distribuido es muy útil, pues con todo esto podemos obtener diversos beneficios para los programadores al momento de realizar los análisis correspondientes, entre los beneficios se puede destacar: Reducir el MTTD (Tiempo medio de detección) y el MTTR (Tiempo medio de reparación),comprender las relaciones de los servicios, Medir acciones específicas de los usuarios. Además, identifica los cuellos de botella y los errores del backend que están perjudicando la experiencia del usuario.

Sin embargo, no todo son ventajas con el rastreo distribuido, también con esto llegan algunas dificultades de su implementación: • Instrumentación manual MTTR: Algunas plataformas de rastreo distribuido requieren que se instrumente o modifique manualmente el código para iniciar el rastreo de las solicitudes. • Muestreo basado en el cabezal: Las plataformas de rastreo tradicionales tienden a muestrear aleatoriamente el rastreo justo cuando comienza cada solicitud. • Cobertura solo backend: A menos que utilice una plataforma de rastreo distribuido de end to end, se genera un ID de rastreo para una solicitud sólo cuando llega al primer servicio de backend. No tendrá visibilidad de la sesión de usuario correspondiente en el frontend.

Más adelánte se darán mayores detalles de estos aspectos.

En la arquitectura de microservicios, una aplicación se descompone en servicios modulares, cada uno de los cuales manejan una función central de la aplicación y suele ser gestionado por un equipo dedicado.

Los microservicios se utilizan para construir muchas aplicaciones modernas porque facilitan la prueba y el despliegue de actualizaciones rápidas y evitan un único punto de fallo. Sin embargo, puede ser difícil solucionar los problemas de los microservicios porque a menudo se ejecutan en un backend complejo y distribuido, y las solicitudes pueden implicar secuencias de múltiples llamadas a servicios por lo que al utilizar el rastreo distribuido de end to end, los desarrolladores pueden visualizar el recorrido completo de una solicitud, desde el frontend hasta el backend, y localizar cualquier fallo de rendimiento o cuello de botella que se haya producido por el camino.

Las plataformas de rastreo distribuido de end to end comienzan a recopilar datos en el momento en que se inicia una solicitud, como cuando un usuario envía un formulario en un sitio web. Esto desencadena la creación de un ID de rastreo único y un tramo inicial, llamado tramo padre, en la plataforma de rastreo.

Un rastreo representa toda la ruta de ejecución de la solicitud, y cada tramo en el rastreo representa una sola unidad de trabajo durante ese viaje, como una llamada a la API o una consulta a la base de datos. Cada vez que la solicitud entra en un servicio, se crea un tramo hijo de nivel superior. Si la solicitud realiza múltiples comandos o consultas dentro del mismo servicio, el tramo hijo de nivel superior puede actuar como padre de otros tramos hijos anidados debajo de él.

La plataforma de rastreo distribuido codifica cada tramo hijo con el ID de rastreo original y un ID de tramo único, datos de duración y error, y metadatos relevantes, como el ID del cliente o la ubicación.

Finalmente, todos los tramos se visualizan en un graph flame, con el tramo padre en la parte superior y los tramos hijos anidados debajo en orden de aparición.

Dado que cada tramo está cronometrado, los ingenieros pueden ver cuánto tiempo pasó la solicitud en cada servicio o base de datos, y priorizar sus esfuerzos de solución de problemas en consecuencia. Los desarrolladores también pueden utilizar el graph flame para determinar qué llamadas presentan errores.

Los ingenieros de frontend, backend y de fiabilidad del sitio utilizan el rastreo distribuido para lograr los siguientes beneficios:

• Reducir el MTTD (tiempo medio de detección) y el MTTR (tiempo medio de reparación, resolución, respuesta o recuperación: Si un cliente informa de que una función de una aplicación es lenta o no funciona, el equipo de soporte puede revisar el rastreo distribuido para determinar si se trata de un problema de backend.

• Los ingenieros pueden entonces analizar el rastreo generado por el servicio afectado para solucionar rápidamente el problema. Si utiliza una herramienta de rastreo distribuido end to end, también podrá investigar los problemas de rendimiento del frontend desde la misma plataforma.

• Comprender las relaciones de los servicios: Al ver el rastreo distribuido, los desarrolladores pueden entender las relaciones causa-efecto entre los servicios y optimizar su rendimiento. Por ejemplo, la visualización de un tramo generado por una llamada a la base de datos puede revelar que la adición de una nueva entrada en la base de datos provoca latencia en un servicio ascendente.

• Medir acciones específicas de los usuarios: El rastreo distribuido ayuda a medir el tiempo que se tarda en completar acciones clave del usuario, como la compra de un artículo. El rastreo puede ayudar a identificar los cuellos de botella y los errores del backend que están perjudicando la experiencia del usuario.

• Mejorar la colaboración y la productividad: En las arquitecturas de microservicios, diferentes equipos pueden ser propietarios de los servicios que intervienen en la realización de una solicitud. El rastreo distribuido deja claro dónde se ha producido un error y qué equipo es responsable de solucionarlo.

• Mantener los Acuerdos de Nivel de Servicio (SLA): La mayoría de las organizaciones tienen acuerdos de nivel de servicio, que son contratos con los clientes u otros equipos internos para cumplir los objetivos de rendimiento. Las herramientas de rastreo distribuido agregan datos de rendimiento de servicios específicos, de modo que los equipos pueden evaluar fácilmente si están cumpliendo los SLA.

A pesar de estas ventajas, existen algunos retos asociados a la implementación del rastreo distribuido:

• Instrumentación manual: Algunas plataformas de rastreo distribuido requieren que se instrumente o modifique manualmente el código para iniciar el rastreo de las solicitudes. La instrumentación manual consume un valioso tiempo de ingeniería y puede introducir errores en su aplicación, pero la necesidad de realizarla suele estar determinada por el lenguaje o el marco de trabajo que se desea instrumentar. La estandarización de las partes de su código a instrumentar también puede hacer que se pierdan los rastreos.

• Muestreo basado en el cabezal: Las plataformas de rastreo tradicionales tienden a muestrear aleatoriamente el rastreo justo cuando comienza cada solicitud. Este enfoque hace que se pierdan rastros o que sean incompletos, con el muestreo basado en cabezas, las empresas no siempre pueden capturar los rastreos que son más relevantes para ellas, como las transacciones de alto valor o las solicitudes de los clientes empresariales.

Por el contrario, algunas plataformas modernas pueden ingerir todos sus rastros y basarse en decisiones basadas en la cola, lo que le permite capturar rastros completos que están etiquetados con atributos relevantes para el negocio, como el ID del cliente o la región.

• Cobertura sólo de backend: A menos que utilice una plataforma de rastreo distribuido de end to end, se genera un ID de rastreo para una solicitud sólo cuando llega al primer servicio de backend. No tendrá visibilidad de la sesión de usuario correspondiente en el frontend.

Esto hace que sea más difícil determinar la causa raíz de una solicitud problemática y si un equipo del frontend o del backend debe solucionar el problema.

Un sistema de alto rendimiento puede generar millones de trazos por minuto, lo que dificulta la identificación y supervisión de los trazos más relevantes para sus aplicaciones. Afortunadamente, existen herramientas que te ayudan a sacar a la luz los datos de rendimiento más útiles.