Introdução

Nas partes anteriores de nossa série, medimos as inicializações a frio da função Lambda com tempo de execução Java 21 sem SnapStart habilitado, com SnapStart habilitado e também aplicamos otimização de preparação de invocação do DynamoDB com diferentes configurações de memória Lambda, tamanhos de artefato de implantação Lambda, Java opções de compilação, (a) clientes HTTP síncronos e o uso de diferentes camadas Lambda. Para todas essas medições usamos algoritmos de coleta de lixo padrão G1.

Neste artigo, gostaríamos de explorar o impacto dos algoritmos de coleta de lixo Java no desempenho da função Lambda com tempo de execução Java 21. Também mediremos novamente tudo para que o G1 tenha resultados comparáveis ​​com a mesma versão secundária do Java 21 em uso para todos os algoritmos de coleta de lixo.

Algoritmos de coleta de lixo Java

Para nossas medições, usaremos os seguintes algoritmos de coleta Java com sua configuração padrão (consulte a documentação vinculada para obter informações mais detalhadas sobre cada algoritmo):

• Coletor de lixo primeiro (G1). Este é o algoritmo de coleta de lixo usado por padrão. Você pode defini-lo explicitamente no modelo AWS SAM adicionando -XX: UseG1GC à variável de ambiente JAVA_TOOL_OPTIONS.
• O coletor paralelo. Você pode defini-lo explicitamente no modelo AWS SAM adicionando -XX: UseParallelGC à variável de ambiente JAVA_TOOL_OPTIONS.
• Shenandoah GC. O Oracle JDK não fornece isso, mas o Amazon Corretto 21 JDK fornece. Você pode defini-lo explicitamente no modelo AWS SAM adicionando -XX: UseShenandoahGC à variável de ambiente JAVA_TOOL_OPTIONS.
• O coletor de lixo Z. Existem 2 algoritmos ZGC diferentes: o padrão e o mais recente de uma geração. Você pode defini-lo explicitamente no modelo AWS SAM adicionando -XX: UseZGC ou -XX: UseZGC -XX: ZGenerational à variável de ambiente JAVA_TOOL_OPTIONS.

Medindo partidas a frio e a quente com Java 21 usando diferentes algoritmos de coleta de lixo

Em nosso experimento usaremos um aplicativo ligeiramente modificado apresentado na parte 9. Você pode encontrar o código do aplicativo aqui. Existem basicamente 2 funções Lambda que respondem às solicitações do API Gateway e recuperam o produto pelo ID recebido do API Gateway do DynamoDB. Uma função Lambda GetProductByIdWithPureJava21LambdaWithGCAlg pode ser usada com e sem SnapStart e a segunda GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg usa preparação de invocação de solicitação SnapStart e DynamoDB.

Os resultados do experimento abaixo foram baseados na reprodução de mais de 100 partidas frias e aproximadamente 100.000 partidas quentes com um experimento que durou aproximadamente 1 hora. 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. Executamos experimentos fornecendo às funções Lambda 1.024 MB de memória e usando JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1" (compilação do cliente Java sem criação de perfil), que tem uma troca muito boa entre tempos de inicialização frio e quente.

Infelizmente não consegui fazer a função Lambda iniciar com o Z Garbage Collector (com o padrão e o geracional) apresentando o erro:

Falha ao confirmar memória (operação não permitida) [erro][gc] Forçado a diminuir o tamanho máximo de heap Java de 872M(100%) para 0M(0%) [erro][gc] Falha ao alocar heap Java inicial (512M) Erro: não foi possível criar a Java Virtual Machine. Erro: Ocorreu uma exceção fatal. O programa será encerrado.

Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Ele tentou configurações de memória maiores, como 1.024, 2.048 MB e ainda mais MBs, mas o mesmo erro ainda apareceu.

Vamos analisar os resultados de nossas medições com outros três algoritmos de coleta de lixo.

Abreviatura

c é para partida a frio e w é para partida a quente.

Hora de início frio (c) e quente (w) sem SnapStart ativado em ms:

Hora de início frio (c) e quente (w) com SnapStart ativado sem Priming em ms:

Hora de início fria (c) e quente (w) com SnapStart habilitado e com invocação do DynamoDB Priming em ms:

Conclusão

Neste artigo, exploramos o impacto dos algoritmos de coleta de lixo Java (G1, Parallel Collector e Shenandoah) no desempenho da função Lambda com Java 21 runtime. Vimos uma grande diferença entre o desempenho desses algoritmos. Usando as configurações padrão com G1 (padrão), experimentamos (às vezes de longe) os tempos de inicialização mais baixos a frio e a quente. Ao usar o SnapStart com preparação da solicitação do DynamoDB, os resultados de desempenho são esperados, muito mais próximos uns dos outros.

Consulte a documentação de cada algoritmo de coleta de lixo para ajustar configurações como mix e memória máxima, que podem fornecer melhoria significativa no desempenho e fazer suas próprias medições.