Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques pour AWS SDK for Java 2.x

Cette section répertorie les meilleures pratiques relatives à l'utilisation du SDK pour Java 2.x.

Réutilisez un client SDK, si possible

Chaque client SDK gère son propre pool de connexions HTTP. Une connexion qui existe déjà dans le pool peut être réutilisée par une nouvelle demande afin de réduire le temps nécessaire à l'établissement d'une nouvelle connexion. Nous vous recommandons de partager une seule instance du client afin d'éviter les surcharges liées à un trop grand nombre de pools de connexions qui ne sont pas utilisés efficacement. Tous les clients du SDK sont compatibles avec les threads.

Si vous ne souhaitez pas partager une instance client, faites appel close() à l'instance pour libérer les ressources lorsque le client n'est pas nécessaire.

Fermez les flux d'entrée provenant des opérations du client

Pour les opérations de streaming telles queS3Client#getObject, par exemple, si vous travaillez ResponseInputStream directement avec, nous vous recommandons de procéder comme suit :

Nous faisons ces recommandations car le flux d'entrée est un flux direct de données provenant de la connexion HTTP et la connexion HTTP sous-jacente ne peut pas être réutilisée tant que toutes les données du flux n'ont pas été lues et que le flux n'est pas fermé. Si ces règles ne sont pas respectées, le client risque de manquer de ressources en allouant un trop grand nombre de connexions HTTP ouvertes mais non utilisées.

Ajustez les configurations HTTP en fonction de tests de performance

Le SDK fournit un ensemble de configurations HTTP par défaut qui s'appliquent aux cas d'utilisation généraux. Nous recommandons aux clients d'ajuster les configurations HTTP de leurs applications en fonction de leurs cas d'utilisation.

Comme bon point de départ, le SDK propose une fonctionnalité intelligente de configuration par défaut. Cette fonctionnalité est disponible à partir de la version 2.17.102. Vous choisissez un mode en fonction de votre cas d'utilisation, qui fournit des valeurs de configuration pertinentes.

Utiliser OpenSSL pour le client HTTP basé sur Netty

Par défaut, le SDK NettyNioAsyncHttpClientutilise l'implémentation SSL par défaut du JDK comme. SslProvider Nos tests ont révélé qu'OpenSSL fonctionne mieux que l'implémentation par défaut du JDK. La communauté Netty recommande également d'utiliser OpenSSL.

Pour utiliser OpenSSL, netty-tcnative complétez vos dépendances. Pour plus de détails sur la configuration, consultez la documentation du projet Netty.

Après avoir netty-tcnative configuré votre projet, l'NettyNioAsyncHttpClientinstance sélectionnera automatiquement OpenSSL. Vous pouvez également définir le SslProvider explicitement à l'aide du NettyNioAsyncHttpClient générateur, comme indiqué dans l'extrait de code suivant.

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

Configurer les délais d'expiration de l'API

Le SDK fournit des valeurs par défaut pour certaines options de temporisation, telles que les délais de connexion et les délais d'expiration des sockets, mais pas pour les délais d'expiration des appels d'API ou les délais d'expiration des tentatives d'appels d'API individuels. Il est recommandé de définir des délais d'expiration à la fois pour les tentatives individuelles et pour l'ensemble de la demande. Cela garantira un échec rapide et optimal de votre application en cas de problèmes transitoires susceptibles de retarder le traitement des demandes ou de provoquer des problèmes réseau fatals.

Vous pouvez configurer des délais d'expiration pour toutes les demandes effectuées par les clients d'un service à l'aide de ClientOverrideConfiguration#apiCallAttemptTimeout etClientOverrideConfiguration#apiCallTimeout.

L'exemple suivant montre la configuration d'un client Amazon S3 avec des valeurs de délai d'expiration personnalisées.

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

Au lieu de définir ces valeurs de délai d'expiration sur le client de service, vous pouvez utiliser RequestOverrideConfiguration#apiCallTimeout()et RequestOverrideConfiguration#apiCallAttemptTimeout() configurer une seule demande.

L'exemple suivant configure une seule listBuckets demande avec des valeurs de délai d'expiration personnalisées.

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

Lorsque vous utilisez ces propriétés ensemble, vous fixez une limite stricte au temps total consacré à toutes les tentatives entre les tentatives. Vous pouvez également configurer une requête HTTP individuelle pour qu'elle échoue rapidement en cas de requête lente.

Utiliser les métriques

Le SDK for Java peut collecter des métriques pour les clients de service de votre application. Vous pouvez utiliser ces indicateurs pour identifier les problèmes de performance, examiner les tendances générales d'utilisation, examiner les exceptions renvoyées par les clients du service ou pour approfondir la compréhension d'un problème particulier.

Nous vous recommandons de collecter des métriques, puis d'analyser les Amazon CloudWatch Logs afin de mieux comprendre les performances de votre application.