Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento lista as práticas recomendadas para usar a API Cloud Healthcare.
As diretrizes desta página foram projetadas para maior eficiência, precisão e tempos de resposta ideais do serviço.
Como entender o desempenho da latência
O desempenho da API Cloud Healthcare é medido pela latência entre:
Enviar uma solicitação para a API Cloud Healthcare.
Quando você recebe uma resposta completa para a solicitação.
A latência é composta por três componentes:
Tempo de retorno (RTT, na sigla em inglês)
Latência de processamento do servidor
Capacidade do servidor
A distância geográfica entre você e o servidor para o qual você está fazendo solicitações pode ter um impacto significativo no RTT e na capacidade do servidor. A latência e a capacidade distribuídas entre regiões para Google Cloud redes podem ser encontradas em um
painel em tempo real.
O painel mostra o desempenho que um cliente pode esperar de diferentes locais ao fazer solicitações a servidores da API Cloud Healthcare.
Como medir o desempenho de latência
As ferramentas e os painéis a seguir fornecem maneiras de avaliar o desempenho de solicitações de e para servidores da API Cloud Healthcare:
Métricas de latência do consoleGoogle Cloud : é possível conferir a latência do servidor das solicitações da API Cloud Healthcare no consoleGoogle Cloud .
Para mais informações, consulte MétricasGoogle Cloud .
Métricas personalizadas do Cloud Logging: é possível criar métricas de distribuição usando o Logging. As métricas de distribuição permitem configurar e entender a latência de ponta a ponta nos seus aplicativos. Também é possível monitorar e relatar as medidas de latência personalizadas.
Nesta seção, descrevemos vários métodos de redução da latência das solicitações enviadas à API Cloud Healthcare.
Como enviar solicitações para o local regional mais próximo
Para conseguir o melhor desempenho de RTT e capacidade de servidor, envie solicitações do cliente para o local regional mais próximo da API Cloud Healthcare. Consulte uma lista de regiões disponíveis em Regiões.
Como enviar solicitações de aquecimento
Quando um cliente envia solicitações a um servidor da API Cloud Healthcare pela primeira vez durante uma sessão, o cliente executa handshakes TCP com o servidor para estabelecer conexões para solicitações HTTP. Qualquer solicitação subsequente pode continuar usando essas conexões estabelecidas, permitindo que o cliente evite a sobrecarga TCP normalmente associada a uma solicitação. Isso resulta em melhor desempenho ao enviar solicitações.
Como enviar solicitações simultaneamente com HTTP/1.1 ou HTTP/2
Para conseguir o melhor desempenho de uma série de solicitações, envie as solicitações simultaneamente. Use as seguintes diretrizes ao enviar solicitações simultâneas:
Ao enviar solicitações simultâneas, tente encontrar um número ideal para o número de solicitações simultâneas. O número ideal depende de vários fatores, incluindo os recursos de hardware e rede e quantas solicitações estão sendo enviadas.
Realize testes para encontrar o número ideal.
Envie solicitações do cliente usando HTTP/2 sempre que possível. O HTTP/2 oferece melhor desempenho do que o HTTP/1.1, porque ele requer apenas uma conexão TCP ao enviar várias solicitações sequencial ou simultaneamente. Como resultado, você pode evitar a sobrecarga de handshake TCP.
Se não for possível usar HTTP/2, use HTTP/1.1 com uma conexão permanente.
Evite a sobrecarga de handshake do TCP se as solicitações de aquecimento já tiverem sido enviadas. O uso de uma conexão persistente pode exigir que você gerencie uma conexão otimizada com um pool de conexões para sua biblioteca HTTP.
PoolingHttpClientConnectionManagercm=newPoolingHttpClientConnectionManager();// Support 20 concurrent requests.cm.setDefaultMaxPerRoute(20);cm.setMaxTotal(100);HTTP_CLIENT=HttpClients.custom().setConnectionManager(cm).build();
Para definir um pool de conexão com 20 solicitações simultâneas usando o Node.js, seu código incluiria o seguinte:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 UTC."],[[["\u003cp\u003eThis document outlines best practices for enhancing efficiency, accuracy, and response times when using the Cloud Healthcare API.\u003c/p\u003e\n"],["\u003cp\u003eLatency in the Cloud Healthcare API is determined by the time between sending a request and receiving a full response, and is impacted by factors like round-trip time (RTT) and server throughput.\u003c/p\u003e\n"],["\u003cp\u003eTools like Google Cloud console latency metrics, Cloud Logging custom metrics, and the Chrome network panel can be used to measure the performance of requests to and from Cloud Healthcare API servers.\u003c/p\u003e\n"],["\u003cp\u003eTo reduce request latency, send requests to the nearest Cloud Healthcare API regional location, send warmup requests to establish connections, and send concurrent requests using HTTP/2 or HTTP/1.1 with persistent connections.\u003c/p\u003e\n"],["\u003cp\u003eUsing a persistent connection might require you to manage an optimized connection with a connection pool for your HTTP library, and the number of concurrent requests should be tested for your specific usage.\u003c/p\u003e\n"]]],[],null,["# Network latency best practices\n\nThis document lists best practices for using the Cloud Healthcare API.\nThe guidelines in this page are designed for greater efficiency, accuracy, and\noptimal response times from the service.\n\nUnderstanding latency performance\n---------------------------------\n\nThe performance of the Cloud Healthcare API is measured by the latency\nbetween:\n\n1. When you send a request to the Cloud Healthcare API.\n2. When you receive a full response to the request.\n\nLatency comprises three components:\n\n- Round-trip time (RTT)\n- Server processing latency\n- Server throughput\n\nThe geographical distance between you and the server you are making requests\nto can have a significant impact on RTT and server throughput. The measured\ninter-region latency and throughput for Google Cloud networks can be found in a\n[live dashboard](https://lookerstudio.google.com/c/u/0/reporting/fc733b10-9744-4a72-a502-92290f608571/page/70YCB).\nThe dashboard shows the performance a client can expect from different\nlocations when making requests to Cloud Healthcare API servers.\n\nMeasuring latency performance\n-----------------------------\n\nThe following tools and dashboards provide ways to measure the performance\nof requests to and from Cloud Healthcare API servers:\n\n- **Google Cloud console latency metrics** : You can view the server-side latency\n of Cloud Healthcare API requests in the [Google Cloud console](https://console.cloud.google.com/apis/api/healthcare.googleapis.com/metrics).\n For more information, see [Google Cloud metrics](/monitoring/api/metrics_gcp).\n\n- **Cloud Logging custom metrics** : You can [create distribution metrics](/logging/docs/logs-based-metrics/distribution-metrics)\n using Logging. Distribution metrics let you configure and\n understand end-to-end latency in your applications. You can also monitor and\n report on any custom-defined latency measurements.\n\n- **Chrome network panel** : You can [inspect network activity in Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/network)\n to view the performance details of an HTTP request sent from a browser.\n\nReducing request latency\n------------------------\n\nThis section describes various methods of reducing the latency of requests sent\nto the Cloud Healthcare API.\n\n### Sending requests to the closest regional location\n\nTo get the best RTT and server throughput performance, send requests from the\nclient to the closest Cloud Healthcare API regional location. See\n[Regions](/healthcare-api/docs/concepts/regions) for a list of available regions.\n\n### Sending warmup requests\n\nWhen a client sends requests to a Cloud Healthcare API server for the\nfirst time during a session, the client performs TCP handshakes with the\nserver to establish connections for HTTP requests. Any subsequent requests\ncan continue to use these established connections, allowing the client to\navoid the TCP overhead typically associated with a request. This results\nin better performance when sending requests.\n\n### Sending requests concurrently with HTTP/1.1 or HTTP/2\n\nTo obtain the best performance for a series of requests, send the requests\nconcurrently. Use the following guidelines when sending concurrent requests:\n\n- When sending concurrent requests, try to find an ideal number for the number of concurrent requests. The ideal number depends on several factors including your hardware and network capabilities and how many requests are being sent. Conduct tests to find the ideal number.\n- Send requests from the client using HTTP/2 whenever possible. HTTP/2 provides better performance than HTTP/1.1 because HTTP/2 requires only one TCP connection when sending multiple requests sequentially or concurrently. As a result, you can avoid TCP handshake overhead.\n- If it's not possible to use HTTP/2, use HTTP/1.1 with a persistent connection.\n You can avoid TCP handshake overhead if [warmup requests](#sending_warmup_requests)\n have already been sent. Using a persistent connection might require you to\n manage an optimized connection with a connection pool for your HTTP library.\n\n For example, to set a connection pool with 20 concurrent requests using the [Google HTTP client library for Java](https://github.com/googleapis/google-http-java-client), your code would include the following: \n\n PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();\n // Support 20 concurrent requests.\n cm.setDefaultMaxPerRoute(20);\n cm.setMaxTotal(100);\n HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();\n\n To set a connection pool with 20 concurrent requests using Node.js, your code\n would include the following: \n\n require('http').globalAgent.maxSockets = 20"]]
