Bonnes pratiques concernant la latence du réseau

Ce document répertorie les bonnes pratiques à suivre pour utiliser l'API Cloud Healthcare. Les directives de cette page sont conçues pour améliorer l'efficacité, la précision et le temps de réponse du service.

Comprendre les performances de latence

Les performances de l'API Cloud Healthcare sont mesurées par la latence entre :

  1. Le moment où vous envoyez une requête à l'API Cloud Healthcare.
  2. Le moment où vous recevez une réponse complète à la requête.

La latence comprend trois composants :

  • Délai aller-retour (DAR)
  • Latence de traitement du serveur
  • Débit du serveur

La distance géographique entre vous et le serveur auquel vous envoyez des requêtes peut avoir un impact significatif sur le DAR et le débit du serveur. Les mesures de latence interrégionale et le débit des réseaux Google Cloud sont indiqués dans un tableau de bord en direct. Le tableau de bord affiche les performances qu'un client peut attendre de différents emplacements lorsqu'il envoie des requêtes aux serveurs de l'API Cloud Healthcare.

Mesurer les performances de latence

Les outils et tableaux de bord suivants permettent de mesurer les performances des requêtes envoyées vers et depuis les serveurs de l'API Cloud Healthcare :

  • Métriques de latence de la console Google Cloud: vous pouvez afficher la latence côté serveur des requêtes de l'API Cloud Healthcare dans la console Google Cloud. Pour en savoir plus, consultez la section Métriques Google Cloud.

  • Métriques personnalisées Cloud Logging : vous pouvez créer des métriques de distribution à l'aide de Logging. Les métriques de distribution vous permettent de configurer et de comprendre la latence de bout en bout dans vos applications. Vous pouvez également surveiller les métriques de latence définies par l'utilisateur et générer des rapports les concernant.

  • Panneau réseau Chrome : vous pouvez inspecter l'activité du réseau dans Chrome DevTools pour afficher les détails d'une requête HTTP envoyée depuis un navigateur.

Réduire la latence des requêtes

Cette section décrit diverses méthodes permettant de réduire la latence des requêtes envoyées à l'API Cloud Healthcare.

Envoyer des requêtes à l'emplacement régional le plus proche

Pour optimiser les performances du DAR et du débit du serveur, envoyez les requêtes depuis le client à l'emplacement régional de l'API Cloud Healthcare le plus proche. Pour obtenir la liste des régions disponibles, consultez la section Régions.

Envoyer des requêtes de préchauffage

Lorsqu'un client envoie des requêtes à un serveur d'API Cloud Healthcare pour la première fois lors d'une session, le client effectue des handshakes TCP avec le serveur afin d'établir des connexions pour les requêtes HTTP. Toute requête ultérieure peut continuer à utiliser ces connexions établies, ce qui permet au client d'éviter les frais TCP généralement associés à une requête. Cela se traduit par de meilleures performances lors de l'envoi de requêtes.

Envoyer des requêtes simultanément avec HTTP/1.1 ou HTTP/2

Pour obtenir les meilleures performances d'une série de requêtes, envoyez les requêtes simultanément. Suivez les instructions ci-dessous pour envoyer des requêtes simultanées :

  • Lorsque vous envoyez des requêtes simultanées, essayez de trouver un nombre idéal pour le nombre de requêtes simultanées. Le nombre idéal dépend de plusieurs facteurs, tels que les capacités matérielles et du réseau, et le nombre de requêtes envoyées. Effectuez des tests pour trouver le nombre idéal.
  • Dans la mesure du possible, envoyez des requêtes à partir du client via HTTP/2. Le protocole HTTP/2 offre de meilleures performances que HTTP/1.1, car HTTP/2 ne nécessite qu'une seule connexion TCP lors de l'envoi séquentiel ou simultané de plusieurs requêtes. Par conséquent, vous pouvez éviter les frais de handshake TCP.

  • S'il n'est pas possible d'utiliser HTTP/2, utilisez HTTP/1.1 avec une connexion persistante. Vous pouvez éviter les frais de handshake TCP si des requêtes de préchauffage ont déjà été envoyées. L'utilisation d'une connexion persistante peut vous obliger à gérer une connexion optimisée avec un pool de connexions pour votre bibliothèque HTTP.

    Par exemple, pour définir un pool de connexions avec 20 requêtes simultanées à l'aide de la bibliothèque cliente HTTP Google pour Java, votre code doit inclure les éléments suivants :

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Support 20 concurrent requests.
cm.setDefaultMaxPerRoute(20);
cm.setMaxTotal(100);
HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();

    Pour définir un pool de connexions avec 20 requêtes simultanées à l'aide de Node.js, votre code doit inclure les éléments suivants :

    require('http').globalAgent.maxSockets = 20