Grandes mejoras de rendimiento para Assemblies más rápidas

Nos complace mucho anunciar que, durante las últimas semanas, hemos realizado mejoras de rendimiento considerables que harán que la Assembly promedio se ejecute aproximadamente entre un 20 y un 40 % más rápido.

«Prueba de rendimiento»

Ejecutamos algunas pruebas con subidas de 1 imagen, 5 imágenes, 10 imágenes y 20 imágenes en nuestra página de demostración de /image/resize EN (English). Es básica, pero ya muestra cuánto hemos mejorado. Aquí tienes un gist⁠ con los resultados. Todos los números que allí aparecen incluyen el tiempo de subida y el de encoding.

Puedes ver que obtuvimos una mejora del 54 % con 5 imágenes, del 25 % con 10 imágenes y del 34 % con 20 imágenes. Con 1 imagen, incluso vimos un aumento de velocidad del 60 %. La mejora de rendimiento es menor cuantos más archivos subes, porque mientras algunos archivos todavía se están subiendo, los demás ya se han convertido. Eso significa que hay menos pérdida de tiempo, incluso con la versión sin mejorar. Cuantos menos archivos haya en la Assembly, más evidente resulta la mejora de rendimiento.

Eso también significa que, en tu Assembly promedio con solo uno o unos pocos archivos, verás un aumento de velocidad tremendo.

¿Cómo lo hicimos?

Para el lector interesado, nos gustaría explicar cómo lo hicimos. 😄

Hicimos algunas mejoras importantes en nuestro sistema para optimizar las cosas. Aunque nos enorgullece que todo nuestro encoding y manipulación de archivos ya se ejecute en paralelo siempre que es posible, había margen para una mejora de este tipo en otra área.

Cuando subes archivos a nuestro servicio, primero necesitamos extraer sus metadatos para a) devolvértelos más adelante, b) que los Robots determinen qué archivos pueden manejar y c) que el Robot /file/filter haga su magia.

Además, necesitamos almacenar todos los archivos subidos y los resultados de encoding en nuestros buckets temporales de Amazon S3 para la comunicación entre máquinas. Si una máquina de encoding necesita un archivo, este debe descargarse desde Amazon S3 y no desde otra máquina de encoding; de lo contrario, se podrían superar fácilmente los límites de E/S de las máquinas y causar problemas.

Tenemos dos tipos de máquinas en producción (en realidad hay más, pero eso es irrelevante para la optimización): máquinas de subida y máquinas de encoding. Las máquinas de subida están detrás de nuestro balanceador de carga, gestionan tus Assemblies entrantes y envían Jobs a las colas. Las máquinas de encoding toman esos Jobs y realizan el encoding, antes de informar de sus resultados. Una vez que se han acumulado todos los resultados, la máquina de subida que gestiona tu Assembly informa al cliente conectado o envía una Notification si usas un notify_url.

Optimización 1

Trasladamos la extracción de metadatos de los archivos subidos de las máquinas de subida a las máquinas de encoding. Eso elimina gran parte de la carga de las máquinas de subida y hace que respondan mejor y sean más fiables, lo que supone un beneficio adicional muy agradable de todo esto. Como nuestra flota está formada en su mayoría por máquinas de encoding, ahora dedicamos mucha más potencia de cómputo a la tarea de extracción de metadatos. Eso hace que se lleve a cabo mucho más rápido.

La desventaja es que ahora las máquinas de encoding primero tienen que descargar los archivos subidos desde las máquinas de subida, lo que implicó que tuviéramos que construir otro sistema de colas más para ello (para asegurarnos de no superar los límites de E/S). Todavía hay más margen de mejora, pero lo comentaremos en un anuncio aparte.

Optimización 2

Ahora también dejamos que las máquinas de encoding almacenen los archivos subidos en S3, en lugar de hacerlo en las máquinas de subida. Además, en vez de realizar ambas tareas (el almacenamiento en S3 y la extracción de metadatos) de forma sucesiva, hicimos cambios para poder ejecutarlas en paralelo. Estos cambios también se aplicaron a los archivos de resultados de encoding.

Optimización 3

Hace poco cambiamos nuestro software de S3 subyacente, de la herramienta AWS de Tim Kay⁠ a la AWS Command Line Interface⁠ oficial. Tim Kay ha hecho un trabajo maravilloso manteniendo una utilidad aws con buen rendimiento, pero Amazon lanza funciones y nuevos centros de datos con frecuencia y, si queremos estar al día, no podemos esperar que Tim Kay dedique cada hora libre a una herramienta que puso a disposición de todos de forma gratuita. Como parecía que Transloadit había llegado a depender de esta utilidad más que su propio autor, decidimos que sería más seguro y justo cambiar a la CLI oficial de Amazon.

Sin embargo, la CLI oficial de AWS exige que añadas el parámetro --region correcto a las llamadas que le haces; de lo contrario, informará de un error. Los buckets de S3 dependen de la región.

Nuestros clientes a menudo no definen el parámetro region al exportar a sus buckets y tampoco hay forma de averiguarlo sin hacer primero peticiones GetBucketLocation y reintentos que consumen mucho tiempo.

Sin embargo, muchas veces los clientes añaden una cadena de región al nombre de su bucket específico de esa región. Esto también es cierto para los buckets temporales regionales de Transloadit, que se usan para la comunicación entre máquinas y afectan a todas las Assemblies.

Decidimos aplicar el sencillo truco de buscar primero regiones válidas en el nombre del bucket y, si existe alguna, usarla como región predeterminada en nuestro primer intento.

Por supuesto, esto no es infalible, pero estamos en el terreno de la optimización del rendimiento, donde los trucos están permitidos. En cualquier caso, nuestro algoritmo funcional para cambiar de región sigue vigente, por si alguien tuviera buckets de EE. UU. con eu-west-1 en sus nombres.

Solo con esto, pudimos reducir el tiempo que tarda en completarse una operación de S3 de 2,5 s a 0,6 s, con lo que ahorramos tiempo valioso en cada paso.

Puedes ver cómo esto beneficia sobre todo a las Assemblies fuera de EE. UU., que tienen archivos de poco tamaño y un número elevado de Steps. Si eres un cliente con sede en EE. UU. que también atiende a usuarios en Europa, esas también son Assemblies fuera de EE. UU. y, por lo tanto, esta mejora de rendimiento también se aplica a ti.

Perspectivas

Nos esforzamos constantemente por ofrecerte un mejor servicio y seguiremos desarrollando mejoras que incrementen aún más el rendimiento del sistema. ¡Mantente atento!

P. D.: Nos gustaría aplaudir a Tim Kay por su trabajo. Es asombroso que la herramienta que publicó funcionara tan bien, 5 años antes que la CLI de AWS. Si nuestro Perl-fu fuera mejor, habríamos ayudado con las tareas de mantenimiento y probablemente todavía la usaríamos.