Renders un 20 % más rápidos, midiendo en vez de suponer

Un render es una cadena: leer la página, escribir el storyboard, grabar la web, grabar la voz y componer el vídeo fotograma a fotograma con Remotion. En un vídeo típico de 19,5 segundos, el trabajo completo tardaba 122 segundos, y 108 eran del compositor. Todo lo demás junto era casi nada.

Lo que marca la velocidad del compositor es cuántos fotogramas pinta el navegador a la vez. Con el mismo vídeo, cronometramos distintos números de workers:

• un worker de fotogramas: 55 segundos;
• dos workers: 33 segundos;
• tres workers: 25 segundos;
• cuatro workers: 23 segundos.

Producción usaba dos. La curva dice que tres es el punto justo: una gran mejora sobre dos, y casi nada más con un cuarto.

¿Por qué dos? Por la memoria. Cada worker de fotogramas es una pestaña del navegador con el vídeo, sus imágenes y sus decodificadores, y los renders se ejecutan en Cloud Run con una memoria fija. En algún momento se decidió que dos workers era la cifra segura. Nadie había mirado cuánto usaba de verdad la máquina.

Así que lo miramos. La monitorización de la plataforma guarda una serie de memoria de cada render, y leímos su percentil 99 de catorce días. Los renders llegaban como máximo al 61 % de sus 8 GiB, unos 4,9 GiB, con tres gigas sin tocar en dos semanas de vídeos reales. El límite que respetábamos era uno al que nunca nos habíamos acercado.

La nueva máquina tiene 4 vCPU, 12 GiB y tres workers de fotogramas. Nuestro modelo de memoria preveía un pico del 44 % del nuevo tamaño en lugar del 61 %.

Al leer la configuración encontramos un mismo ajuste haciendo dos trabajos. Controlaba a la vez los fotogramas pintados en paralelo dentro de un render y el número de renders completos que aceptaría a la vez un worker de cola.

Hoy cada render se ejecuta solo y termina, así que el segundo significado nunca entraba en juego. Pero si algún día se activara la cola, una máquina ajustada para tres fotogramas en paralelo habría aceptado tres vídeos enteros a la vez. La cola tiene ahora su propio ajuste, que sigue en un vídeo cada vez. Un nombre, un significado es la seguridad más barata que existe.

También hicimos que cada documento que describe la máquina diga el mismo tamaño, para que la próxima persona que la ajuste parta de la realidad.

Una suposición que se pone por escrito suele acabar pareciendo un hecho. Así que la nueva configuración está protegida por un test que hace fallar el build si alguna de estas condiciones deja de cumplirse:

• tres workers caben en la memoria declarada con un 30 % de margen;
• nunca más workers de fotogramas que núcleos, con un núcleo libre para el codificador de vídeo;
• el límite de tiempo cubre de sobra el vídeo más largo que se puede pedir;
• cada archivo que describe la máquina indica el tamaño realmente desplegado.

También dejamos por escrito un experimento que no cambió nada, para que nadie lo repita. Triplicar la caché de vídeo con un vídeo pensado para ponerla a prueba dio 64,3 segundos frente a 64,2, con un resultado idéntico, así que la caché mantiene su tamaño.

Una prueba en un portátil y dos semanas de lecturas son una proyección, no un resultado. Así que antes de acabar la noche comprobamos las dos cosas con renders reales.

Setenta renders de vídeos de 20 a 40 segundos con dos workers promediaban 5,93 veces el tiempo real. Los cuatro primeros con tres workers promediaron 4,75 veces el tiempo real: un 20 % más rápidos aproximadamente, cada uno más rápido que al menos el 77 % de los setenta. Muestra pequeña, dirección clara.

La memoria llegó como máximo al 42 % de los 12 GiB, 5,04 GiB, frente a los 5,32 GiB que preveía nuestro modelo. El modelo tira a pesimista, que es la forma correcta de equivocarse cuando la alternativa es un render que se queda sin sitio. Así que se queda, con una regla más en el test: el modelo nunca puede prever menos de lo que luego usan los vídeos reales. Puedes leer más sobre cómo se hacen los vídeos en la página de funciones.