Partilhar via


Latência no Armazenamento de blobs

A latência, por vezes referenciada como tempo de resposta, é a quantidade de tempo que uma aplicação tem de aguardar pela conclusão de um pedido. A latência pode afetar diretamente o desempenho de uma aplicação. A baixa latência é muitas vezes importante para cenários com humanos em ciclo, como realizar transações de cartões de crédito ou carregar páginas Web. Os sistemas que precisam de processar eventos recebidos a taxas elevadas, como o registo de telemetria ou eventos IoT, também requerem baixa latência. Este artigo descreve como compreender e medir a latência para operações em blobs de blocos e como estruturar as suas aplicações para baixa latência.

O Armazenamento do Azure oferece duas opções de desempenho diferentes para blobs de blocos: premium e standard. Os blobs de blocos Premium oferecem uma latência significativamente mais baixa e consistente do que os blobs de blocos padrão através de discos SSD de elevado desempenho. Para obter mais informações, veja Armazenamento de blobs de blocos de desempenho Premium nas camadas de acesso Frequente, Esporádico e Arquivo para dados de blobs.

Acerca da latência do Armazenamento do Azure

A latência do Armazenamento do Azure está relacionada com as taxas de pedidos das operações do Armazenamento do Azure. As taxas de pedido também são conhecidas como operações de entrada/saída por segundo (IOPS).

Para calcular a taxa de pedidos, determine primeiro o período de tempo que cada pedido demora a concluir e, em seguida, calcule quantos pedidos podem ser processados por segundo. Por exemplo, suponha que um pedido demora 50 milissegundos (ms) a concluir. Uma aplicação que utilize um thread com uma operação de leitura ou escrita pendente deve alcançar 20 IOPS (1 segundo ou 1000 ms/50 ms por pedido). Teoricamente, se a contagem de threads for duplicada para duas, a aplicação deverá conseguir atingir 40 IOPS. Se as operações de leitura ou escrita assíncronas pendentes para cada thread forem duplicadas para duas, a aplicação deverá conseguir alcançar 80 IOPS.

Na prática, as taxas de pedido nem sempre são dimensionadas de forma tão linear, devido à sobrecarga no cliente do agendamento de tarefas, mudança de contexto, etc. Do lado do serviço, pode haver variabilidade na latência devido à pressão sobre o sistema de Armazenamento do Azure, diferenças no suporte de dados de armazenamento utilizado, ruído de outras cargas de trabalho, tarefas de manutenção e outros fatores. Por fim, a ligação de rede entre o cliente e o servidor pode afetar a latência do Armazenamento do Microsoft Azure devido a congestionamento, reencaminhamento ou outras interrupções.

A largura de banda do Armazenamento do Azure, também conhecida como débito, está relacionada com a taxa de pedidos e pode ser calculada ao multiplicar a taxa de pedidos (IOPS) pelo tamanho do pedido. Por exemplo, assumindo 160 pedidos por segundo, cada 256 KiB de dados resulta num débito de 40.960 KiB por segundo ou 40 MiB por segundo.

Métricas de latência para blobs de blocos

O Armazenamento do Azure fornece duas métricas de latência para blobs de blocos. Estas métricas podem ser visualizadas no portal do Azure:

  • A latência ponto a ponto (E2E) mede o intervalo a partir do momento em que o Armazenamento do Azure recebe o primeiro pacote do pedido até que o Armazenamento do Azure receba uma confirmação do cliente no último pacote da resposta.

  • A latência do servidor mede o intervalo de quando o Armazenamento do Azure recebe o último pacote do pedido até que o primeiro pacote da resposta seja devolvido do Armazenamento do Microsoft Azure.

A imagem seguinte mostra a Latência Média de Êxito E2E e a Latência Média do Servidor de Êxito para uma carga de trabalho de exemplo que chama a Get Blob operação:

Captura de ecrã a mostrar as métricas de latência para a operação Obter Blob

Em condições normais, existe pouca diferença entre a latência ponto a ponto e a latência do servidor, que é o que a imagem mostra para a carga de trabalho de exemplo.

Se analisar as métricas de latência ponto a ponto e do servidor e verificar que a latência ponto a ponto é significativamente superior à latência do servidor, investigue e resolva a origem da latência adicional.

Se a latência ponto a ponto e do servidor forem semelhantes, mas precisar de latência mais baixa, considere migrar para o armazenamento de blobs de blocos premium.

Fatores que influenciam a latência

O principal fator que influencia a latência é o tamanho da operação. Demora mais tempo a concluir operações maiores, devido à quantidade de dados a serem transferidos através da rede e processados pelo Armazenamento do Azure.

O diagrama seguinte mostra o tempo total para operações de vários tamanhos. Para pequenas quantidades de dados, o intervalo de latência é predominantemente gasto a processar o pedido, em vez de transferir dados. O intervalo de latência aumenta apenas ligeiramente à medida que o tamanho da operação aumenta (marcado como 1 no diagrama abaixo). À medida que o tamanho da operação aumenta, é gasto mais tempo na transferência de dados, para que o intervalo de latência total seja dividido entre o processamento de pedidos e a transferência de dados (marcado como 2 no diagrama abaixo). Com tamanhos de operação maiores, o intervalo de latência é quase exclusivamente gasto na transferência de dados e o processamento de pedidos é em grande parte insignificante (marcado como 3 no diagrama abaixo).

Captura de ecrã a mostrar o tempo total da operação por tamanho da operação

Os fatores de configuração do cliente, como simultaneidade e threading, também afetam a latência. O débito geral depende do número de pedidos de armazenamento em curso num determinado momento e da forma como a sua aplicação processa os threads. Os recursos do cliente, incluindo CPU, memória, armazenamento local e interfaces de rede também podem afetar a latência.

O processamento de pedidos de Armazenamento do Azure requer recursos de CPU e memória do cliente. Se o cliente estiver sob pressão devido a uma máquina virtual com pouco poder ou a algum processo em execução no sistema, existem menos recursos disponíveis para processar pedidos de Armazenamento do Azure. Qualquer contenção ou falta de recursos de cliente resultará num aumento da latência ponto a ponto sem um aumento da latência do servidor, aumentando o intervalo entre as duas métricas.

Igualmente importante é a interface de rede e o pipe de rede entre o cliente e o Armazenamento do Azure. A distância física por si só pode ser um fator significativo, por exemplo, se uma VM cliente estiver numa região do Azure diferente ou no local. Outros fatores, como os saltos de rede, o encaminhamento isp e o estado da Internet, podem influenciar a latência de armazenamento geral.

Para avaliar a latência, primeiro estabeleça métricas de linha de base para o seu cenário. As métricas de linha de base fornecem-lhe a latência ponto a ponto e do servidor esperadas no contexto do ambiente da aplicação, consoante o perfil de carga de trabalho, as definições de configuração da aplicação, os recursos do cliente, o pipe de rede e outros fatores. Quando tem métricas de linha de base, pode identificar mais facilmente condições anormais versus normais. As métricas de linha de base também lhe permitem observar os efeitos dos parâmetros alterados, como a configuração da aplicação ou os tamanhos das VMs.

Passos seguintes