As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Perguntas frequentes
Como configuro o cliente HTTP do meu SDK? Há alguma diretriz ou prática recomendada?
Não podemos fornecer orientação aos clientes sobre como configurar seu fluxo de trabalho HTTP da maneira mais eficaz para sua carga de trabalho específica. A resposta para isso é o produto de uma equação multivariada, com fatores de entrada incluindo, mas não se limitando a:
-
a área de cobertura de rede do aplicativo (TPS, taxa de transferência etc.)
-
os serviços que estão sendo usados
-
as características computacionais da implantação
-
a natureza geográfica da implantação
-
o comportamento desejado do aplicativo ou as necessidades do próprio aplicativo (SLAs, horários etc.)
Como devo configurar os tempos limite de operação?
Assim como na pergunta anterior, isso depende. Os elementos a serem considerados aqui incluem o seguinte:
-
Todos os fatores acima relacionados à configuração do cliente HTTP
-
Seu próprio tempo de aplicação ou restrições de SLA (por exemplo, se você mesmo distribuir tráfego para outros consumidores)
A resposta a essa pergunta quase NUNCA deve ser baseada na observação empírica pura do comportamento inicial - por exemplo, “Fiz 1000 chamadas para esta operação, demorou no máximo 5 segundos, então vou definir o tempo limite com base nisso com um fator de segurança de 2x a 10 segundos”. As condições ambientais podem mudar, os serviços podem se degradar temporariamente e esses tipos de suposições podem se tornar erradas sem aviso prévio.
As solicitações feitas pelo SDK estão atingindo o tempo limite ou demorando muito. Como faço para corrigir isso?
Não podemos ajudar com chamadas de operação estendidas ou expiradas devido ao tempo prolongado gasto na rede. O “tempo de conexão” no SDK é definido como qualquer um dos seguintes:
-
Tempo gasto no método de um cliente SDK
HTTPClient.Do() -
Tempo gasto em
Read()s em um corpo de resposta HTTP que foi encaminhado ao chamador (por exemplo)GetObject
Se você estiver enfrentando problemas devido à latência da operação ou ao tempo limite, sua primeira ação deve ser obter a telemetria do ciclo de vida da operação do SDK para determinar a interrupção do tempo entre o tempo gasto na conexão e a sobrecarga da operação ao redor. Consulte o guia sobre cronometragem de operações do SDK, que contém um trecho de código reutilizável que pode fazer isso.
Como faço para corrigir um read: connection reset erro?
O SDK tenta novamente quaisquer erros que correspondam ao connection reset padrão por padrão. Isso abrangerá o tratamento de erros na maioria das operações, em que a resposta HTTP da operação é totalmente consumida e desserializada em seu tipo de resultado modelado.
No entanto, esse erro ainda pode ocorrer em um contexto fora do loop de repetição: certas operações de serviço encaminham diretamente o corpo da resposta HTTP da API para o chamador, para ser consumido diretamente da rede io.ReadCloser (por exemplo, carga útil GetObject do objeto). Você pode encontrar esse erro ao executar um Read no corpo da resposta.
Esse erro indica que seu host, o serviço ou qualquer intermediário (por exemplo, gateways NAT, proxies, balanceadores de carga) fechou a conexão ao tentar ler a resposta.
Isso pode ocorrer por vários motivos:
-
Você não consumiu o corpo da resposta por algum tempo depois que a resposta em si foi recebida (depois que a operação de serviço foi chamada). Recomendamos que você consuma o corpo da resposta HTTP o mais rápido possível para esses tipos de operações.
-
Você não fechou um corpo de resposta recebido anteriormente. Isso pode causar redefinições de conexão em determinadas plataformas. Você DEVE fechar todas
io.ReadCloseras instâncias fornecidas na resposta de uma operação, independentemente de consumir seu conteúdo.
Além disso, tente executar a tcpdump para uma conexão afetada na borda da sua rede (por exemplo, após qualquer proxy que você controle). Se você perceber que o AWS endpoint parece estar enviando um TCP RST, use o console de AWS suporte para abrir um processo contra o serviço ofensivo. Esteja preparado para fornecer solicitações IDs e registros de data e hora específicos de quando o problema ocorreu.
Por que estou recebendo erros de “assinatura inválida” ao usar um proxy HTTP com o SDK?
O algoritmo de assinatura para AWS serviços (geralmente sigv4) está vinculado aos cabeçalhos da solicitação serializada, mais especificamente à maioria dos cabeçalhos prefixados com. X- Os proxies tendem a modificar a solicitação de saída adicionando informações adicionais de encaminhamento (geralmente por meio de um X-Forwarded-For cabeçalho), o que efetivamente quebra a assinatura calculada pelo SDK.
Se você estiver usando um proxy HTTP e tiver erros de assinatura, trabalhe para capturar a solicitação conforme ela aparece saindo do proxy e determinar se ela é diferente.
