Práticas recomendadas do AWS SDK for Java 2.x

Esta seção lista as melhores práticas para usar o SDK para Java 2.x.

Reutilizar um cliente do SDK, se possível

Cada cliente do SDK mantém seu próprio grupo de conexões HTTP. Uma conexão que já existe no grupo pode ser reutilizada por uma nova solicitação para reduzir o tempo de estabelecimento de uma nova conexão. Recomendamos compartilhar uma única instância do cliente para evitar a sobrecarga de ter muitos grupos de conexão que não são usados de forma eficaz. Todos os clientes do SDK são seguros para os threads.

Se você não quiser compartilhar uma instância do cliente, chame close() na instância para liberar os recursos quando o cliente não for necessário.

Fechar os streams de entrada das operações do cliente

Para operações de streaming, como S3Client#getObject, se você estiver trabalhando diretamente com ResponseInputStream, recomendamos fazer o seguinte:

• Leia todos os dados do stream de entrada o mais rápido possível.

• Feche o stream de entrada o mais rápido possível.

Fazemos essas recomendações porque o stream de entrada é um stream direto de dados da conexão HTTP e a conexão HTTP subjacente não pode ser reutilizada até que todos os dados do stream tenham sido lidos e o stream seja fechado. Se essas regras não forem seguidas, o cliente poderá ficar sem recursos alocando muitas conexões HTTP abertas, mas não utilizadas.

Ajustar as configurações HTTP com base em testes de desempenho

O SDK fornece um conjunto de configurações http padrão que se aplicam a casos de uso gerais. Recomendamos que os clientes ajustem as configurações HTTP para seus aplicativos com base em seus casos de uso.

Como um bom ponto de partida, o SDK oferece um atributo de padrões de configuração inteligentes. Esse atributo está disponível somente na versão 2.17.102. Escolha um modo de acordo com seu caso de uso que forneça valores de configuração sensatos.

Usar o OpenSSL para o cliente HTTP baseado no Netty

Por padrão, o NettyNioAsyncHttpClient do SDK usa a implementação SSL padrão do JDK como o SslProvider. Nossos testes descobriram que o OpenSSL tem um desempenho melhor do que a implementação padrão do JDK. A comunidade do Netty também recomenda o uso do OpenSSL.

Para usar o OpenSSL, adicione netty-tcnative às suas dependências. Para obter detalhes de configuração, consulte a Documentação do projeto Netty.

Depois de configurar netty-tcnative para seu projeto, a instância NettyNioAsyncHttpClient selecionará automaticamente o OpenSSL. Você também pode definir o SslProvider explicitamente usando o construtor NettyNioAsyncHttpClient, conforme mostrado no trecho a seguir.

NettyNioAsyncHttpClient.builder()
                        .sslProvider(SslProvider.OPENSSL)
                        .build();

Configurar tempos limite da API

O SDK fornece valores padrão para algumas opções de tempos limite, como tempo limite de conexão e tempo limite de soquete, mas não para tempos limite de chamadas de API ou tempos limite de tentativas de chamadas de API individuais. É uma boa prática definir tempos limite para as tentativas individuais e para toda a solicitação. Isso garantirá que seu aplicativo se antecipe à falha de maneira ideal quando houver problemas transitórios que podem fazer com que as tentativas de solicitação demorem mais para serem concluídas ou problemas fatais na rede.

Você pode configurar tempos limite para todas as solicitações feitas por clientes de um serviço usando ClientOverrideConfiguration#apiCallAttemptTimeout e ClientOverrideConfiguration#apiCallTimeout.

O exemplo a seguir mostra a configuração de um cliente do Amazon S3 com valores de tempo limite personalizados.

S3Client.builder()
        .overrideConfiguration(
             b -> b.apiCallTimeout(Duration.ofSeconds(<custom value>))
                   .apiCallAttemptTimeout(Duration.ofMillis(<custom value>)))
        .build();

apiCallAttemptTimeout

Essa configuração define a quantidade de tempo para uma única tentativa de HTTP, após o qual a chamada de API pode ser repetida.

apiCallTimeout

O valor dessa propriedade configura a quantidade de tempo para toda a execução, incluindo todas as tentativas de repetição.

Como alternativa para definir esses valores de tempo limite no cliente de serviço, você pode usar RequestOverrideConfiguration#apiCallTimeout() e RequestOverrideConfiguration#apiCallAttemptTimeout() para configurar uma única solicitação.

O exemplo a seguir configura uma única solicitação listBuckets com valores de tempo limite personalizados.

s3Client.listBuckets(lbr -> lbr.overrideConfiguration(
        b -> b.apiCallTimeout(Duration.ofSeconds(<custom value>))
               .apiCallAttemptTimeout(Duration.ofMillis(<custom value>))));

Ao usar essas propriedades em conjunto, você define um limite rígido para o tempo total gasto em todas as tentativas das repetições. Você também configura uma solicitação HTTP individual para se antecipar à falha rapidamente em uma solicitação lenta.

Usar métricas

O SDK para Java pode coletar métricas para os clientes de serviço em seu aplicativo. Você pode usar essas métricas para identificar problemas de desempenho, analisar as tendências gerais de uso, analisar as exceções retornadas pelos clientes de serviços ou se aprofundar para entender um problema específico.

Recomendamos que você colete métricas e, em seguida, analise o Amazon CloudWatch Logs para obter uma compreensão mais profunda do desempenho do seu aplicativo.