Noticias

Snap Performance Skunk Works – Asegurando velocidad y consistencia para Snaps

Los snaps se utilizan en computadoras de escritorio, servidores y dispositivos de IoT. Sin embargo, es el primer grupo que recibe la mayor atención y escrutinio. Debido a la naturaleza gráfica de las aplicaciones de escritorio, los usuarios a menudo están mejor preparados para lidiar con problemas potenciales y problemas que pueden surgir en el área del escritorio que con herramientas de línea de comandos o software que se ejecutan en segundo plano.

El tiempo de inicio de la aplicación es uno de los temas de discusión más comunes en los foros de Snapcraft, así como en la web. La naturaleza autónoma y limitada de Snaps significa que su proceso de inicio difiere de los programas clásicos de Linux (como los instalados a través de archivos Deb o RPM). Esto a menudo se puede reflejar en tiempos de inicio más largos, que se perciben negativamente. A lo largo de los años, hemos hablado sobre los diversos mecanismos y métodos que se han introducido en el ecosistema Snaps para obtener beneficios de rendimiento: mejoras en la caché de fuentes, cambios en el algoritmo de compresión y otros. Ahora nos gustaría darle un vistazo a una operación de Skunk Works * dentro de Canonical, con énfasis en las instantáneas y la potencia de inicio.

Si bien las mejoras de velocidad siempre son útiles y los usuarios las reciben con gusto, la coherencia de los resultados también es (si no más importante) importante. Una ganancia de un segundo suele ser menos beneficiosa que perder el mismo segundo más adelante en el ciclo de vida del software. Se espera que una aplicación cuyo tiempo de inicio haya mejorado permanezca así, y los usuarios normalmente responderán con mayor negatividad a cada nuevo retraso que a la manifestación original del problema.

Las regresiones de rendimiento son un desafío difícil y están relacionadas con dos aspectos principales del desarrollo de software: cambios reales y tangibles en el código y comprensión y control general del sistema.

Para abordar estos problemas, el equipo de certificación de Canonical utiliza el paquete de software de automatización de pruebas Checkbox para realizar una variedad de pruebas prácticas de regresión y rendimiento para varios productos de Canonical. La herramienta ofrece una gran flexibilidad, incluidas tareas e informes personalizados. Las pruebas instantáneas también están disponibles a través de la utilidad checkbox-desktop-snaps (también distribuida como instantánea).

LEER  DXVK 2.1 ahora disponible, con soporte para espacio de color HDR y HDR10

De forma predeterminada, Checkbox mide las horas de inicio en frío (sin datos en caché) y en caliente (datos en caché) de 10 instantáneas de escritorio prominentes en múltiples plataformas de hardware e informa los resultados. Pero se vuelve realmente interesante cuando miramos la configuración del entorno.

Independientemente de la tecnología y la herramienta utilizadas, medir los tiempos de ejecución en el software puede ser difícil porque es difícil separar (o limpiar) la aplicación en cuestión del sistema general. Un programa de conectividad de red puede informar resultados inconsistentes según el rendimiento y la latencia del tráfico. Los diferentes tipos de discos y la actividad de E / S también afectan la sincronización. Puede haber una actividad de fondo significativa en el dispositivo, que también puede causar ruido y resultados sesgados. La lista de posibles obstáculos sigue y sigue.

En situaciones como estas, que están diseñadas para simular condiciones de uso de la vida real, el punto no es ignorar o eliminar los fenómenos comunes, sino normalizarlos para que produzcan resultados fiables. Por ejemplo, las pruebas repetidas en diferentes momentos del día pueden eliminar algunas de las variaciones en los resultados relacionados con la actividad de la red o del disco.

Con Checkbox y Snaps, hemos decidido dar un paso más, es decir, examinar la influencia tanto de los sistemas operativos como de los Snaps en los resultados de la medición al inicio.

Antes de que podamos afirmar una comprensión completa del sistema, debemos comprender cómo interactúan los diferentes componentes. Muchas variables entran en juego con las instantáneas. Por ejemplo, si un complemento se actualiza y recibe una actualización, ¿podemos tratar los nuevos resultados de inicio como parte del mismo conjunto que las fechas anteriores o como un conjunto nuevo? Si hay una actualización del kernel, ¿podemos o debemos esperar que los tiempos de inicio de Snap no cambien?

Aislar las diversas permutaciones de una máquina Linux típica no es un asunto trivial. Para ello, decidimos crear dos series de pruebas diferentes:

  • Los sistemas inmutables que no tienen actualizaciones y solo las instantáneas instaladas cambian con actualizaciones regulares. Siempre que hay una actualización instantánea, se inicia la prueba de la casilla de verificación y se recopilan nuevos datos. Esta es una excelente manera de determinar si un cambio en los tiempos de inicio, para bien o para mal, se debió a los cambios reales en las aplicaciones Snap.
  • Las instantáneas inmutables se han probado en sistemas que están recibiendo actualizaciones. Aquí mantenemos las instantáneas vinculadas a una versión específica (por ejemplo, Firefox 89, VLC 3.0.8) y luego activamos las pruebas cuando se produce un cambio de sistema en uno de los cinco componentes críticos: kernel, glibc, controlador de gráficos, apparmor y snapped. De esta manera podemos correlacionar todos los cambios en el comportamiento de inicio de una o más instantáneas con las actualizaciones del sistema.
Ejemplo de la prueba de tiempo de inicio de Firefox en un sistema inmutable en una plataforma de hardware de muestra. Las líneas azules indican cada actualización de Firefox en el canal beta. Las pruebas abarcan varias versiones del sistema operativo (se muestra 04/20). La mejora significativa en el arranque en frío que se puede ver en el lado derecho del diagrama ahora se remonta a los cambios específicos que se introdujeron en el diseño respectivo del Snap.

Ejecutamos las pruebas con varias configuraciones:

  • Hardware con dos tarjetas gráficas diferentes.
  • Hardware con discos duros mecánicos y SSD.
  • Versiones LTS compatibles y la última imagen de desarrollo.

La naturaleza extensible de la herramienta Checkbox le permite incluir cualquier número de instantáneas, cualquier número de instantáneas y se pueden agregar pruebas personalizadas según sea necesario. Además de las horas de inicio, la herramienta puede, por ejemplo, recopilar capturas de pantalla, que luego también permiten una comparación visual de los resultados, como posibles inconsistencias en el tema entre diferentes instantáneas, entornos de escritorio y diferentes versiones de entornos de escritorio.

Cuando comenzamos a recopilar los números de las horas de inicio, nos enfocamos en los números reales. Sin embargo, en general, estos valores son menos importantes que las diferencias relativas en los resultados recopilados en diferentes condiciones para los mismos Snaps, en la misma configuración de hardware. Por ejemplo, ¿cómo cambia la hora de inicio rápido cuando se cambia de una imagen LTS a otra? ¿Las actualizaciones del kernel afectan los resultados?

Ahora que hemos determinado cómo se comportan los Snaps en diferentes condiciones operativas, podemos crear una línea de base. Valores mínimos y máximos, tiempos medios y otros parámetros para los que podemos crear alertas. Esto nos permite, como parte de nuestras pruebas, identificar resultados potencialmente malos en un comportamiento de Snap e inmediatamente marcar cambios en el sistema (o actualizaciones de Snap) que podrían resultar en una experiencia de usuario degradada.

La recopilación y el análisis de los datos de la hora de inicio de Snap va mucho más allá para garantizar que los Snaps se inicien rápidamente y que los usuarios tengan una buena experiencia. El mecanismo también nos permite comprender mucho mejor la compleja interacción entre hardware y software, así como varios componentes del sistema operativo. A medida que ampliemos nuestro trabajo con la herramienta Checkbox, podremos crear fórmulas complejas que nos digan cómo las actualizaciones del kernel, los parches del sistema o quizás las actualizaciones instantáneas afectan el rendimiento de inicio. Ya sabemos que el uso de la compresión LZO para el empaquetado instantáneo puede resultar en mejoras del 50-60%. ¿Quizás agregar una nueva biblioteca en poco tiempo pueda hacer una gran diferencia? ¿O tal vez ciertas distribuciones son más rápidas que otras?

Por el momento, Checkbox está diseñado para funcionar en el entorno de escritorio GNOME, pero también tenemos compilaciones de prueba que también pueden recopilar datos en KDE y Xfce. Mejoramos constantemente el marco y buscamos formas de mejorar su usabilidad: descarga lateral más fácil de pruebas, personalización de pruebas, configuración, exportación de datos, etc. Si tiene algún comentario o idea, únase a nuestro foro y háganoslo saber.

Artículo de Igor Ljubuncic y Sylvain Pineau.

* Skunk Works es un seudónimo oficial de Lockheed Martins Advanced Development Programs (ADP), anteriormente llamado Lockheed Advanced Development Projects, acuñado en la década de 1940 y utilizado por corporaciones y corporaciones desde entonces por su estilo fresco, fuera de banda, misterioso o cortante. proyectos de vanguardia.

Foto de Lalo Hernandez en Unsplash.

LEER  Primera DockerCon de Canonical | Ubuntu

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba