BT

Comparando o desempenho de plataformas Serverless

| por Hrishikesh Barua Seguir 16 Seguidores , traduzido por Gibran Silva Seguir 0 Seguidores em 24 out 2018. Tempo estimado de leitura: 2 minutos |

A maioria dos provedores de nuvem tem plataformas serverless que oferecem o recurso de function as a service (FaaS). Um estudo recente compilou as diferenças entre essas plataformas, comparando seu desempenho de execução, cold start time, dependências e alocação de recursos.

AWS Lamba, Google Cloud Functions, Azure Functions e IBM Cloud Functions foram as plataformas serverless testadas por Bernd Strehi para comparar seu desempenho. Embora os testes tenham sido executados utilizando funções em Node.js, os testes revelam alguns fatos sobre como estas soluções respondem a solicitações variáveis de carga. A metodologia de testes tem sido criticada pelo pequeno tamanho dos testes, assim como pelo fato de não levar em conta outros fatores como tipo de instâncias subjacentes. Testes de outras equipes adotaram diferentes abordagens.

Provedores de serverless cobram não somente por CPU, memória e número de requisições, mas também por rede e armazenamento. Os provedores analisados diferem entre si em como eles ajustam a memória para requisitos específicos de CPU. A AWS, por exemplo, fornece mais ciclos de CPU para instâncias que possuem mais memória. O Google segue uma estratégia similar, enquanto a Azure varia em como a CPU é alocada com "4-vCPU VMs tendendo a ter mais compartilhamentos de CPU".

Solicitações simultâneas alteram o tempo médio de resposta de uma função. Para uma solicitação não simultânea, a alocação de um recurso permanece quase o igual para todos os provedores, exceto para o Google, que varia em torno de 30%. O tempo de computação na AWS aumentou 46% para solicitações simultâneas quando a mesma chamada foi realizada 50 vezes ao mesmo tempo. Para o Google e Azure este aumento foi de 7% e 3% respectivamente, enquanto na IBM o aumento foi de 154%. Outros testes revelam que a AWS tem o melhor desempenho para execuções simultâneas.

Cold start time é o tempo necessário para uma função serverless responder a primeira solicitação depois de ficar sem uso por algum tempo. Conforme os resultados apresentados aqui, manter o desempenho constante é um desafio para todos os provedores de serverless. A primeira solicitação configura uma instância do servidor e o prepara para executá-la, e a instância é mantida viva depois da primeira solicitação. No entanto, o tempo que a instância permanece viva varia para cada provedor.

Mikhail Shilkov, no artigo mediu 20 minutos como sendo o tempo para a Azure e os tempos variaram para o Google Cloud Functions. A AWS menciona oficialmente como 5 minutos o seu cold start time, mas na prática o tempo é maior dado os ajustes realizados pelo seu time de engenharia. Cold starts também pode ocorrer quando o serviço tem que escalar horizontalmente e novas instâncias precisam ser ativadas.

A escolha do runtime também afeta o desempenho. O Node.js não precisa de muita CPU para iniciar, enquanto o runtime de .NET Core exige mais memória (no caso da AWS Lambda). Cold start times diminuem com o aumento da alocação da memória. Para Javascript, o teste revelaram que AWS foi a mais rápida no cold start times, seguido pelo Google Cloud Plataform e Azure.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
BT