En este post quería compartir algunos apuntes referidos a lo que aprendí en WOPR #28 en mayo 2019, en Marsella, Francia. Tuve el honor de poder asistir a esta conferencia organizada por Eric Proegler y Paul Holland en las oficinas de Neotys, donde compartí 2 días y medio junto a 13 expertos en el área de pruebas de performance.
No había una agenda fija, sino que las charlas se intentaba que no duren más de 30 minutos, donde sólo se pueden hacer preguntas para clarificar. Todos los comentarios o preguntas sobre el tema expuesto se hacen luego en lo que le llaman “open season” siguiendo una dinámica llamada K-cards. Esta dinámica fue moderada por Paul de una manera notable. Podés ver en su blog sobre cómo se dirige esta dinámica.
Un evento súper enriquecedor. Tomé algunos apuntes que los quiero compartir acá, pero no reflejan ni cerca de todo lo que fue el intercambio con toda esta gente.
Amazing workshop we had in Marseille these days! A total of 14 performance testers with different views on the topic sharing 2.5 days at @WOPR_Workshop. Thanks to the organizers @ericproegler and @PaulHolland_TWN and @Neotys for hosting! pic.twitter.com/7xPY2ERSDA
— Federico Toledo (@fltoledo) May 31, 2019
Pruebas de carga
Henrik fue el primero en exponer. Algo que me gustó mucho de su apertura a la charla fue que habló del concepto de pruebas de carga, la típica historia de que provienen de las pruebas en ingeniería civil de probar puentes por ejemplo, pero contó una historia bastante particular. Contó sobre una prueba de carga sobre un puente en el que se consideraron distintas variables: el efecto del viento que hace que se balancee el puente, y el peso que tenía que soportar.
Hicieron diversas pruebas donde estas variables las probaron por separado. En producción se dieron las dos a la vez (mucho peso y balanceo por el viento) y eso hizo que el puente colapse. Moraleja, hay que considerar cómo se pueden combinar las distintas variables en producción.
Sobre datos
Se estuvo hablando sobre lo malo que son los promedios. Hace un tiempo había escrito hace un tiempo sobre el tema también.
Acá hay un thread en Twitter bien interesante al respecto, no trata sobre una discusión dada en el WOPR pero la compartieron y conversamos al respecto:
If you’re wondering what “P-four-nines” means, it’s the latency at the 99.99th percentile, meaning only one in 10,000 requests has a worse latency. Why do we measure latency in percentiles?
— Andrew Certain (@tacertain) May 25, 2019
A thread about how how it came to be at Amazon…https://t.co/OCGSc5c6KZ
Más links interesantes para leer sobre el tema:
- https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/
- https://www.circonus.com/2018/08/latency-slos-done-right/
- https://en.wikipedia.org/wiki/Power_law
Otro tema que dio que hablar fue sobre lo malo que es confiar en los datos agregados. Cuando uno accede a los datos de un APM o de una herramienta de pruebas de performance los datos no están “en crudo”, sino que estas herramientas para optimizar temas de espacio de disco para guardar estos datos, hacen promedios cada ciertos rangos de tiempo (ejemplo: no almacenan los datos de cada segundo sino que guardan el promedio cada 5 minutos). Esto puede complicar o limitar mucho un análisis de un cuello de botella o alguna anomalía. Sobre el tema compartieron esta presentación que habla del tema.
Uno de los participantes dejó también sus comentarios en este post.
Se habló sobre varias herramientas para visualizar datos, y si bien no es barata, una que me gustó mucho es Tableau.
Modelado de escenarios de carga
Hicimos un brainstorming entre todos sobre todo lo que hay que tener en cuenta para el modelado de escenarios. El ejercicio estuvo súper bueno. Acá dejo las fotos de los dos pizarrones que completamos, a pesar que me cuesta entender la letra 🙂
Lo que me resulta interesante es poder hacer este ejercicio en un equipo de trabajo al inicio de una prueba de performance y tal vez representarlo en un mind-map.
Keptn
Andy Grabner nos presentó un proyecto opensource en el que está trabajando llamado Keptn.
Arrancó haciendo una analogía bien interesante con enviar un cohete a la luna y sacar un software a producción. Hay dos equipos para esto, primero uno que se encarga del despegue, el launch control, y otro que toma la dirección del proyecto una vez que despega que es el mission control. Esto sería como el equipo de desarrollo y el equipo de operaciones.
Esta herramienta soluciona distintos aspectos del deploy, pudiendo cada equipo hacer lo suyo, tanto el equipo de desarrollo para el deploy como el de operaciones para cuando ya está en producción.
Acá hay un post al respecto y acá están las slides.
UFO para CI/CD
Como sobró un poco de tiempo, la última charla cortita fue sobre un proyecto similar al del UFO para CI/CD. Básicamente, un tablero con luces que muestra fácilmente el estado del build en el entorno de CI/CD para que todos puedan tener una visión de cómo está el sistema.
No todo es performance
El evento tuvo muchas actividades extras a las presentaciones que permitió que nos conociéramos más entre los participantes. Nos sacaron a recorrer el parque cercano a Marsella, cenamos por ahí en la costa y salimos por el centro de la ciudad.
Fueron tres días formidables y con mucho aprendizaje y compartir. Espero haya sido el primer WOPR de muchos más.
One thought on “Algunas notas del WOPR 28”