Grandes melhorias de desempenho para Assemblies mais rápidas

Temos o prazer de anunciar que, nas últimas semanas, fizemos melhorias consideráveis de desempenho, que farão a Assembly média ser executada cerca de 20 a 40% mais rápido.

“Teste de desempenho”

Fizemos alguns testes com uploads de 1 imagem, 5 imagens, 10 imagens e 20 imagens na nossa página de demonstração do /image/resize EN (English). É um teste simples, mas já mostra o quanto melhoramos. Aqui está um gist⁠ com os resultados. Todos os números ali incluem o tempo de upload e de codificação.

Você pode ver que tivemos uma melhoria de 54% para 5 imagens, 25% para 10 imagens e 34% para 20 imagens. Para 1 imagem, observamos até um aumento de 60% na velocidade. A melhoria de desempenho fica menor quanto mais arquivos você envia, porque, enquanto alguns arquivos ainda estão sendo enviados, os outros já foram convertidos. Isso significa que há menos perda de tempo, mesmo na versão sem as melhorias. Quanto menos arquivos houver na Assembly, mais evidente fica a melhoria de desempenho.

Isso também significa que, na sua Assembly média, com apenas um ou poucos arquivos, você verá um aumento enorme de velocidade.

Como fizemos isso?

Para quem tiver interesse, gostaríamos de explicar como fizemos isso. 😄

Fizemos algumas grandes melhorias no nosso sistema para otimizar as coisas. Embora nos orgulhemos de que toda a nossa codificação e manipulação de arquivos já seja executada em paralelo sempre que possível, havia espaço para esse tipo de melhoria em outra área.

Quando você envia arquivos para o nosso serviço, primeiro precisamos extrair os metadados deles para a) devolvê-los a você mais tarde, b) permitir que os Robots determinem quais arquivos conseguem processar e c) permitir que o Robot /file/filter faça sua mágica.

Além disso, precisamos armazenar todos os arquivos enviados e os resultados de codificação nos nossos buckets temporários do Amazon S3 para a comunicação entre máquinas. Se uma máquina de codificação precisar de um arquivo, ele deve ser baixado do Amazon S3, e não de outra máquina de codificação; caso contrário, isso poderia facilmente exceder os limites de I/O das máquinas e causar problemas.

Temos dois tipos de máquinas (na verdade, mais do que isso, mas isso não é relevante para a otimização) em produção: máquinas de upload e codificadores. As máquinas de upload ficam atrás do nosso balanceador de carga, recebem as suas Assemblies e colocam Jobs em filas. Os codificadores (máquinas de codificação) pegam esses Jobs e os codificam antes de reportar os resultados. Depois que todos os resultados são reunidos, a máquina de upload que cuida da sua Assembly reporta de volta ao cliente conectado ou envia uma Notification se você usar um notify_url.

Otimização 1

Transferimos a extração de metadados dos arquivos enviados das máquinas de upload para as máquinas de codificação. Isso tira uma grande carga das máquinas de upload e as torna mais responsivas e confiáveis, o que é um benefício adicional muito bom de tudo isso. Como a nossa frota é composta principalmente por máquinas de codificação, agora dedicamos muito mais poder computacional à tarefa de extração de metadados. Com isso, ela é realizada muito mais rápido.

A desvantagem é que os codificadores agora precisam primeiro baixar os arquivos enviados das máquinas de upload, o que significou que tivemos de construir mais um sistema de filas para isso (para garantir que o limite de I/O não seja excedido). Ainda há espaço para melhorias, mas vamos tratar disso em um anúncio separado.

Otimização 2

Agora também deixamos que as máquinas de codificação armazenem os arquivos enviados no S3, em vez de fazer isso nas máquinas de upload. Além disso, em vez de executar as duas tarefas (armazenamento no S3 e extração de metadados) em sequência, fizemos mudanças para que agora possamos executá-las em paralelo. Essas mudanças também foram aplicadas aos arquivos de resultado da codificação.

Otimização 3

Recentemente, trocamos o software de S3 que usamos internamente, da ferramenta AWS do Tim Kay⁠ para a AWS Command Line Interface⁠ oficial. Tim Kay fez um trabalho excelente mantendo um utilitário aws de alto desempenho, mas a Amazon lança recursos e novos data centers com frequência e, se quisermos nos manter atualizados, não podemos esperar que Tim Kay dedique cada hora livre a uma ferramenta que ele disponibilizou gratuitamente. Como parecia que a Transloadit tinha passado a depender mais desse utilitário do que o próprio autor, decidimos que seria mais seguro e justo migrar para a CLI oficial da Amazon.

A AWS CLI oficial, no entanto, exige que você adicione o parâmetro --region correto às chamadas; caso contrário, ela reporta um erro. Os buckets do S3 dependem da região.

Nossos clientes muitas vezes não definem o parâmetro region ao exportar para os seus buckets, e também não há como descobri-lo sem antes fazer requisições GetBucketLocation e novas tentativas, que consomem tempo.

Muitas vezes, porém, os clientes incluem uma string de região no nome dos seus buckets específicos de região. Isso também vale para os buckets temporários regionais da Transloadit, que são usados para a comunicação entre máquinas e afetam todas as Assemblies.

Decidimos aplicar o truque simples de primeiro procurar regiões válidas no nome do bucket e, se houver uma, usá-la como região padrão na nossa primeira tentativa.

É claro que isso não é infalível, mas estamos no terreno da otimização de desempenho, onde truques são permitidos. De qualquer forma, nosso algoritmo funcional para trocar de região também continua em vigor, caso alguém tenha buckets nos EUA com eu-west-1 no nome.

Só com isso, conseguimos reduzir o tempo para concluir uma operação no S3 de 2,5 s para 0,6 s, economizando um tempo valioso em cada Step.

Você pode ver como isso beneficia principalmente as Assemblies fora dos EUA, com arquivos pequenos e muitos Steps. Se você é um cliente baseado nos EUA que também atende usuários na Europa, essas também são Assemblies fora dos EUA e, portanto, esse ganho de desempenho também se aplica a você.

Perspectivas

Estamos sempre buscando oferecer um serviço melhor para você e continuaremos criando melhorias que aumentem ainda mais o desempenho do sistema. Fique ligado!

P.S. Gostaríamos de aplaudir Tim Kay pelo seu trabalho. É incrível que a ferramenta que ele publicou tenha funcionado tão bem, 5 anos antes da AWS CLI. Se o nosso Perl-fu fosse um pouco melhor, teríamos ajudado nos esforços de manutenção e provavelmente ainda a usaríamos.