Práticas recomendadas sobre latência de solicitação e tratamento de erros

Esta página descreve as práticas recomendadas para otimizar a latência das solicitações e como lidar com erros na API Cloud Healthcare. Implementação essas práticas conforme você planeja e projeta a arquitetura do sistema.

O Google fornece um contrato de nível de serviço (SLA) que define os tempo de atividade esperado do serviço da API Cloud Healthcare e como os clientes podem lidar com erros. Para mais informações, consulte Contrato de nível de serviço (SLA) do Cloud Healthcare.

Implementar a lógica de repetição e tempos limite

Para lidar com atrasos e erros causados por solicitações com falha, implemente a lógica de repetição e os tempos limite adequados. Ao definir a duração do tempo limite, permita tempo suficiente para fazer o seguinte:

• Deixe a API Cloud Healthcare processar a solicitação.
• Determine se o erro foi originado do serviço ou do cliente.

Alguns erros podem ser repetidos, mas outros não podem ser repetidos e persistem várias tentativas. Por exemplo, se os dados da solicitação estiverem formatados incorretamente, o servidor responde com um código de status 400 Bad Request. A solicitação não ter sucesso até corrigir os dados.

Para lidar com essas situações, você precisa se planejar para os estados de erro finais.

Para mais informações sobre a lógica de repetição e os tempos limite, consulte Repetir solicitações com falha.

Solucionar erros em várias camadas

Quando o middleware interage com a API Cloud Healthcare, implemente a lógica de repetição e tempos limite no cliente e no middleware. Se um cliente encontra erros além do limite de tentativas, será necessário identificar se o erro ocorreu no cliente, no middleware ou no serviço subjacente da API Cloud Healthcare. Isso é especialmente importante quando o planejamento dos estados de erro finais.

Pense no seguinte cenário:

1. O middleware recebe um erro 500 Internal Server Error do API Cloud Healthcare ao enviar uma solicitação.
2. A camada de middleware tenta executar a solicitação mais cinco vezes, alcançando e para de tentar novamente.
3. O cliente recebe um erro 500 Internal Server Error final.

É importante entender que o erro se originou na API Cloud Healthcare, não no middleware. Para simplificar a depuração, forneça essa informação no erro retornado ao para o cliente.

O diagrama a seguir mostra um cenário em que um proxy de middleware recebe 500 Internal Server Error erros ao encaminhar uma solicitação de um cliente para a API Cloud Healthcare. O cliente e o proxy implementam tratamento de erros e novas tentativas.

Às vezes, o cliente ou proxy recebe erros 500 Internal Server Error ultrapassar os limites e não poderá tentar novamente. Nesse caso, um humano pode precisar intervir para diagnosticar se o erro veio do proxy ou do API Cloud Healthcare.

Escolher quais erros tentar novamente

Dependendo da arquitetura do sistema, é possível repetir determinadas e ignorar os outros. Confira a seguir uma lista com alguns exemplos da API Cloud Healthcare que aceitam novas tentativas códigos de erro:

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Esses erros geralmente não ocorrem na mesma frequência e alguns podem nunca ocorrer.

Efeitos da arquitetura do sistema

A arquitetura do seu sistema influencia como e quando você tenta cometer erros.

Por exemplo, em uma arquitetura direta de cliente para servidor, um cliente que recebe um erro 401 UNAUTHENTICATED do A API Cloud Healthcare pode se autenticar outra vez e repetir a solicitação.

Suponha que um sistema tenha uma camada de middleware entre o cliente e a API Cloud Healthcare. Se o cliente foi autenticado corretamente e um token de autenticação expirado causou o problema e, em seguida, o middleware precisa atualizar o token e tente fazer a solicitação novamente.

Depois de analisar os estados de erro finais, você pode ajustar os erros que seu cliente novas tentativas com base em suas descobertas.

Planejar os estados de erro finais

Mesmo após implementar a lógica de repetição e tempos limite, um cliente ou middleware pode receber erros até que as tentativas se esgotem. O último erro retornado antes das novas tentativas e os tempos limite se esgotarem é o estado de erro final. Pode ocorrer um erro final para erros de consistência de dados.

Às vezes, um estado de erro final requer intervenção humana. Tente implementar para resolver o estado de erro final de uma solicitação. Caso contrário, registre o estado de erro final para que um humano possa analisá-lo.

Considere o seguinte ao planejar como lidar com estados de erro finais:

• Se há dependências de processamento que precisam ser interrompidas se uma transação FHIR ou o pacote não foi concluído.
• Se muitas instâncias de máquina virtual (VM) começarem a falhar de forma permanente, uma o cliente precisa informar as solicitações que falharam. Depois que o problema for corrigido, o cliente precisa repetir as solicitações.
• Monitoramento, sistemas de alerta e objetivos de nível de serviço (SLOs) para garantir a estabilidade do seu sistema. Consulte Testar e monitorar para mais informações.

Planejar o aumento da latência

A API Cloud Healthcare é um serviço escalonável e de alto desempenho, mas a latência ainda pode variar pelos seguintes motivos:

• Pequenas diferenças entre as solicitações, mesmo que pareçam insignificantes, podem aumentar o tempo de processamento.
• Solicitações semelhantes podem ter latências diferentes. Por exemplo, duas solicitações semelhantes que adicionam um registro ao armazenamento de dados podem têm latências diferentes se um deles ultrapassar um limite que desencadeie uma tarefa extra, como alocar mais armazenamento.
• A API Cloud Healthcare lida com muitas solicitações simultaneamente. A hora em que um cliente envia uma solicitação, medida em frações de segundo, pode coincidir com um momento em que a API Cloud Healthcare está sob carga mais pesada que o normal.
• Se um recurso físico da API Cloud Healthcare, como um disco, estiver processando muitos solicitações, ele precisa concluir suas tarefas na fila antes de lidar com outras solicitações.
• Às vezes, a API Cloud Healthcare tenta novamente erros no lado do servidor, o que pode aumentar latência de rede para os clientes.
• Pode haver várias cópias de dados em data centers diferentes um local regional ou multirregional. Se as solicitações forem encaminhadas vários data centers, seja na solicitação original ou em uma nova tentativa, pode haver aumento da latência.

Planejar usando a latência de percentil

Você pode planejar o aumento da latência analisando o percentil latência do suas solicitações. A exemplos a seguir descrevem a latência do 50o percentil e os Latência do 99o percentil:

• A latência do 50o percentil é a latência máxima, em segundos, do 50% das solicitações mais rápidas. Por exemplo, se a latência do 50o percentil for 0,5 segundo, a API Cloud Healthcare processou 50% das solicitações em até 0,5 segundo. A latência do 50o percentil também é chamada a "latência mediana".
• A latência do 99o percentil é a latência máxima, em segundos, do com 99% das solicitações mais rápidas. Por exemplo, se a latência do 99o percentil for dois segundos, a API Cloud Healthcare processou 99% das solicitações em dois segundos.

Se você analisar o percentil de latência em um intervalo quando a API Cloud Healthcare só processar algumas solicitações, a latência do percentil pode não ser útil ou indicativo do desempenho geral, porque as solicitações atípicas podem ter uma grande influência.

Por exemplo, suponha que um processo na API Cloud Healthcare processe 100 solicitações em 100 minutos. A latência do 99o percentil durante os 100 minutos ser baseada na solicitação mais lenta. A medição de latência usando um único solicitação não é suficiente para compreender se há resultados problemas.

Coletar uma amostra maior de solicitação para um período mais longo, como 24 horas, pode fornecer mais informações comportamento do seu sistema. Você pode usar esses exemplos para determinar como seu sistema responde a tráfego intenso.