Introdução

Na parte 7 da série Data API for Amazon Aurora Serverless v2 com AWS SDK for Java – Data API atende SnapStart, medimos os tempos de inicialização a frio e a quente da função Lambda conectando-se ao banco de dados Amazon Aurora Serverless v2 PostgreSQL usando Data API para 3 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 otimização de priming (pré-aquecimento da execução de instruções SQL no banco de dados PostgreSQL).

Neste artigo, gostaríamos de comparar essas medições com aquelas, mas com o uso do DynamoDB em vez da API de dados para Amazon Aurora Serverless v2.

Comparando inicializações a frio e a quente do Lambda: API de dados para Amazon Aurora Serverless v2 vs DynamoDB

Em minha série de artigos sobre Lambda SnapStart, já fizemos essas medições para aplicativos semelhantes, mas no artigo Medindo partidas a quente com Java 21 usando diferentes configurações de memória Lambda.

Ambos os aplicativos Data API para Amazon Aurora Serverless v2 e DynamoDB são muito semelhantes:

• Eles fornecem lógica para armazenar e recuperar produtos do banco de dados
• As funções Lambda de ambos os projetos têm configuração de memória de 1024 MB
• Os tamanhos dos artefatos de implantação são em torno de 18 MB para ambos
• As funções Lambda de ambos os projetos usam o cliente HTTP Apache síncrono padrão para se comunicar com bancos de dados
• As funções Lambda de ambos os projetos usam arquitetura x86_64

Agora vamos juntar todas as medições.

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

Conclusão

Neste artigo, comparei medições dos tempos de inicialização a frio e a quente da função Lambda conectando-se ao banco de dados Amazon Aurora Serverless v2 PostgreSQL usando Data API versus conectando-se ao banco de dados DynamoDB para 3 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 priming da solicitação do banco de dados

O que observamos é que os tempos de inicialização a frio sem ativar o SnapStart na função Lambda são bastante comparáveis ​​para ambos. Caso o SnapStart esteja habilitado (sem e especialmente com priming), a API de dados para Amazon Aurora Serverless v2 tem tempos de inicialização a frio significativamente mais altos, especialmente para os percentis >= 90. Precisarei me aprofundar para entender essa diferença, pois não o fiz. espere que seja tão grande, especialmente se o primer tiver sido aplicado. Talvez a razão para isso seja que os serviços nativos da AWS, como o DynamoDB, são mais compatíveis com o SnapStart e posso lidar melhor com retomadas de conexão.

Os tempos de inicialização a quente (execução) foram constantemente muito mais altos para a API de dados do Amazon Aurora Serverless v2 em comparação com o DynamoDB, o que eu também esperava, já que o DynamoDB é conhecido por seus tempos de resposta de milissegundos de um ou dois dígitos.