Bonnes pratiques d'utilisation du AWS SDK for Java 2.x

Empêchez le blocage des demandes en configurant les délais d'expiration des 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 mortels.

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();

apiCallAttemptTimeout

Ce paramètre définit la durée d'une seule tentative HTTP, après laquelle l'appel d'API peut être réessayé.

apiCallTimeout

La valeur de cette propriété configure la durée de l'exécution complète, y compris toutes les tentatives de nouvelle tentative.

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.

Améliorez les performances en réutilisant les clients du service

Chaque client de service 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 service 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.

Empêchez les fuites de ressources en fermant les clients de service non utilisés

Fermez un client de service pour libérer des ressources, telles que des threads, si elles ne sont plus nécessaires. 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.

Empêchez l'épuisement du pool de connexions en fermant les flux d'entrée

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 :

• Lisez toutes les données du flux d'entrée dès que possible.

• Fermez le flux d'entrée dès que possible.

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 peut manquer de ressources en allouant un trop grand nombre de connexions HTTP ouvertes mais non utilisées.

Optimisez les performances HTTP pour la charge de travail de votre application

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.

Améliorez les performances SSL avec OpenSSL pour les clients asynchrones

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();

Surveillez les performances des applications à l'aide des métriques du SDK

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.