Introdução

Até agora, não medi o desempenho (tempos de inicialização a quente e a frio) das funções Lambda usando o tempo de execução Java 21 para alguns casos de uso (como fazer solicitações do DynamoDB) para a arquitetura arm64 porque ela não oferece suporte ao SnapStart. Lambda com tempo de execução Java 21 com arquitetura x86_64 com SnapStart habilitado terá desempenho superior (ainda mais com otimização de priming adicional) Lambda com arquitetura arm64. Mas em 18 de julho de 2024, a AWS anunciou que o AWS Lambda agora oferece suporte ao SnapStart para funções Java que usam a arquitetura ARM64. Portanto, agora fazia sentido começar a medir os tempos de partida a frio e a quente, considerando também a escolha da arquitetura da função Lambda. Sabe-se que com a atual configuração de memória de preços do AWS Lambda e duração de execução, o Lambda com arquitetura arm64 será de aprox. 25% mais barato que Lambda com arquitetura x86_64.

Decidi criar uma série de artigos separada para ele e não adicionar este tópico à minha crescente série AWS Lambda SnapStart.

Medindo as partidas a frio e a quente para a aplicação de exemplo

Em nosso experimento, reutilizaremos o aplicativo apresentado no artigo AWS Lambda SnapStart - Medindo inicializações a frio do Java 21 Lambda. Aqui está o código do aplicativo de exemplo. Existem basicamente 2 funções Lambda principais que respondem às solicitações do API Gateway para criar o produto com o ID fornecido (consulte a função PutProductFunction Lambda) e recuperam o produto pelo ID fornecido (consulte a função GetProductByIdFunction Lambda). Você pode usar as funções do Lambda com e sem o SnapStart habilitado. Há uma função Lambda adicional GetProductByIdWithPrimingFunction que escrevi para medir de forma independente o efeito da preparação de solicitação do DynamoDB para a função Lambda habilitada para SnapStart. Você pode ler mais sobre o efeito do priming em meu artigo AWS Lambda SnapStart – Medindo o priming, latência ponta a ponta e tempo de implantação.

Para ativar o SnapStart em todas as funções do Lambda, remova o comentário do seguinte no modelo SAM:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

Se eu quiser usar o SnapStart apenas para o indivíduo, mas não para todas as funções do Lambda, você deverá aplicar esta definição do SnapStart no nível da função Lambda em vez do nível da função global.

Todas as funções do Lambda têm as seguintes configurações como ponto de partida:

• Configuração de memória de 1024 MB
• Cliente HTTP Apache padrão usado para se comunicar com o banco de dados DynamoDB
• Opção de compilação Java "-XX: TieredCompilation -XX:TieredStopAtLevel=1" que provou fornecer uma troca muito boa entre os tempos de inicialização frio e quente

No modelo SAM adicionei a possibilidade de definir a arquitetura Lambda na seção de função global do Lambda como:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

Basta descomentar a arquitetura que você gostaria de usar para suas funções Lambda.

Mesmo que Java seja "escreva uma vez, execute em qualquer lugar", eu compilei e construí o arquivo jar do aplicativo para minhas medições arm64 na instância t4g AWS EC2 com processador Graviton (que é baseado na arquitetura arm64/aarch64) instalando anteriormente Amazon Corretto 21 para Linux aarch64. Você pode encontrar este frasco aqui.

Eu também medi novamente tudo para a arquitetura x86_64 mais uma vez para obter resultados comparáveis ​​usando a mesma versão de tempo de execução mais recente do Corretto Java 21 que no momento das minhas medições era Java 21.v17 .

Os resultados do experimento abaixo foram baseados na reprodução de mais de 100 partidas a frio e aproximadamente 100.000 partidas a quente. Para isso (e experimentos do meu artigo anterior) usei a ferramenta de teste de carga, ei, mas você pode usar qualquer ferramenta que quiser, como artilharia sem servidor ou Postman. Também é importante estar ciente de que iniciei as medições logo após a (re)implantação do novo código-fonte do aplicativo. Observe que também há impacto do cache em camadas do snapshot nas inicializações a frio, onde as primeiras invocações são geralmente mais lentas e as subsequentes se tornam mais rápidas até que determinado número de invocações seja atingido.

Agora vamos colocar todas as medidas para "obter produto por ID existente" (funções Lambda GetProductByIdFunction e GetProductByIdWithPrimingFunction para SnapStart habilitado e medições de preparação) juntas.

Tempo de início frio (c) e quente (m) em ms:

Conclusão

Neste artigo, comparamos medições dos tempos de inicialização a frio e a quente da função Lambda conectada ao banco de dados DynamoDB para três casos de uso:

• sem SnapStart habilitado na função Lambda
• com SnapStart ativado na função Lambda, mas sem otimização de preparação
• com SnapStart habilitado na função Lambda e com preparação da solicitação DynamoDB

Vimos que ao usar a arquitetura x86_64 todos os tempos de inicialização a frio e a quente foram menores em comparação com a arquitetura arm64. Mas como o preço Lambda da arquitetura arm64 é 25% mais barato que a arquitetura x86_64 , ele apresenta uma compensação custo-desempenho muito interessante.

Para nossas medições, para todos os três casos de uso:

• Os tempos de inicialização a frio do Lambda com arquitetura arm64 foram, para muitos percentis, apenas 10-20% (e apenas em casos muito raros, 25-27%) mais lentos em comparação com a arquitetura x86_64.
• Os tempos de inicialização a quente do Lambda com arquitetura arm64 foram, para muitos percentis, apenas 5-10% mais lentos em comparação com a arquitetura x86_64.

Portanto, a escolha da arquitetura arm64 é bastante razoável para este aplicativo de exemplo. Como o suporte SnapStart para a arquitetura arm64 só foi introduzido recentemente, também espero algumas melhorias de desempenho no futuro. Faça suas próprias medições para seu caso de uso!

Na próxima parte do artigo faremos as mesmas medições de desempenho, mas configurando a memória Lambda para valores diferentes entre 256 e 2048 MBs e compararemos os resultados.