Noções básicas sobre o desempenho dos Arquivos do Azure

2025-04-21

Os Arquivos do Azure podem atender aos requisitos de desempenho da maioria dos aplicativos e dos casos de uso. Este artigo explica os diferentes fatores que podem afetar o desempenho do compartilhamento de arquivo e como otimizar o desempenho dos compartilhamentos de arquivos do Azure para sua carga de trabalho.

Aplica-se a

Modelo de gestão	Modelo de cobrança	Camada de mídia	Redundância
Microsoft.Storage	Provisionado v2	HDD (padrão)	Local (LRS)
Microsoft.Storage	Provisionado v2	HDD (padrão)	Zona (ZRS)
Microsoft.Storage	Provisionado v2	HDD (padrão)	Localização geográfica (GRS)
Microsoft.Storage	Provisionado v2	HDD (padrão)	GeoZone (GZRS)
Microsoft.Storage	Provisionado v1	SSD (de alta qualidade)	Local (LRS)
Microsoft.Storage	Provisionado v1	SSD (de alta qualidade)	Zona (ZRS)
Microsoft.Storage	Pagamento Conforme o Uso	HDD (padrão)	Local (LRS)
Microsoft.Storage	Pagamento Conforme o Uso	HDD (padrão)	Zona (ZRS)
Microsoft.Storage	Pagamento Conforme o Uso	HDD (padrão)	Localização geográfica (GRS)
Microsoft.Storage	Pagamento Conforme o Uso	HDD (padrão)	GeoZone (GZRS)

Glossário

Antes de você ler este artigo, é útil entender alguns termos básicos relacionados ao desempenho do armazenamento:

Operação de E/S por segundo (IOPS)

O IOPS, ou operações de entrada/saída por segundo, mede o número de operações do sistema de arquivos por segundo. O termo "IO" é intercambiável com os termos "operação" e "transação" na documentação dos Arquivos do Azure.
Tamanho de E/S

O tamanho de E/S, às vezes chamado de tamanho de bloco, é o tamanho da solicitação que um aplicativo usa para executar uma operação individual de E/S (entrada/saída) no armazenamento. Dependendo do aplicativo, o tamanho de E/S pode variar de tamanhos pequenos, como 4 KiB a tamanhos maiores. O tamanho de E/S desempenha um papel importante na taxa de transferência alcançável.
Taxa de transferência

A taxa de transferência mede o número de bits lidos ou gravados no armazenamento por segundo e é medida em MiB/s (mebibytes por segundo). Para calcular a taxa de transferência, multiplique a IOPS pelo tamanho da E/S. Por exemplo, 10.000 IOPS * Tamanho de E/S de 1 MiB = 10 GiB/s, enquanto 10.000 IOPS * Tamanho de E/S de 4 KiB = 38 MiB/s.
Latência

A latência é um sinônimo de atraso e é medida em milissegundos (ms). Há dois tipos de latência: latência de ponta a ponta e latência de serviço. Para obter mais informações, confira Latência.
Profundidade da fila

Profundidade da fila é o número de solicitações de E/S pendentes que um recurso de armazenamento pode processar a qualquer momento. Para obter mais informações, confira Profundidade da fila.

Escolhendo uma camada de mídia com base em padrões de uso

Os Arquivos do Azure fornecem duas camadas de mídia de armazenamento que permitem balancear o desempenho e o preço: SSD e HDD. Você escolhe a camada de mídia do compartilhamento de arquivos no nível da conta de armazenamento e, depois de criar uma conta de armazenamento em uma determinada camada de mídia, não é possível mover para a outra sem migrar manualmente para um novo compartilhamento de arquivos.

Ao escolher entre compartilhamentos de arquivos SSD e HDD, é importante entender os requisitos do padrão de uso esperado que você está planejando executar nos Arquivos do Azure. Se você precisar de grandes quantidades de IOPS, velocidades rápidas de transferência de dados ou baixa latência, deverá escolher compartilhamentos de arquivos SSD.

A tabela a seguir resume as metas de desempenho esperadas entre compartilhamentos de arquivos SSD e HDD. Para obter detalhes, confira Metas de desempenho e escalabilidade dos Arquivos do Azure.

Requisitos de padrão de uso	SSD	HDD
Latência de gravação (milissegundos de dígito único)	Sim	Sim
Latência de leitura (milissegundos de dígito único)	Sim	Não

Os compartilhamentos de arquivos SSD oferecem um modelo de provisionamento que garante o seguinte perfil de desempenho com base no tamanho do compartilhamento. Para obter mais informações, veja o modelo v1 provisionado.

Lista de verificação de desempenho

Se você estiver avaliando os requisitos de desempenho para uma carga de trabalho nova ou existente, entender seus padrões de uso ajuda você a alcançar um desempenho previsível.

Sensibilidade de latência: As cargas de trabalho que são sensíveis à latência de leitura e têm alta visibilidade para os usuários finais são mais adequadas para compartilhamentos de arquivos SSD, que podem fornecer latência de milissegundo único para operações de leitura e gravação (< 2 ms para tamanho pequeno de E/S).
Requisitos de IOPS e taxa de transferência: Os compartilhamentos de arquivos SSD dão suporte a IOPS e limites de taxa de transferência maiores do que os compartilhamentos de arquivos HDD. Confira metas e tamanhos do compartilhamento de arquivos para obter mais informações.
Duração e frequência da carga de trabalho: Cargas de trabalho curtas (minutos) e pouco frequentes (por hora) são menos propensas a atingir os limites de desempenho superiores dos compartilhamentos de arquivos HDD em comparação com cargas de trabalho de execução longa e frequentes. Em compartilhamentos de arquivos SSD, a duração da carga de trabalho é útil ao determinar o perfil de desempenho correto a ser usado com base no armazenamento provisionado, IOPS e taxa de transferência. Um erro comum é executar testes de desempenho por apenas alguns minutos, o que geralmente é enganoso. Para ter uma visão realista do desempenho, faça testes em uma frequência e uma duração suficientemente altas.
Paralelização da carga de trabalho: Para cargas de trabalho que executam operações em paralelo, como por meio de vários threads, processos ou instâncias de aplicativo no mesmo cliente, os compartilhamentos de arquivos SSD fornecem uma clara vantagem sobre os compartilhamentos de arquivos HDD: SMB Multichannel. Veja Melhore o desempenho do compartilhamento de arquivos do SMB Azure para obter mais informações.
Distribuição da operação de API: cargas de trabalho intensivas em metadados, como aquelas que realizam operações de leitura em um grande número de arquivos, são mais adequadas para compartilhamentos de arquivos SSD. Veja Carga de trabalho pesada de metadados ou namespace.

Latência

Ao pensar em latência, é importante, primeiro, entender como a latência é determinada com os Arquivos do Azure. As medidas mais comuns são a latência associada às métricas latência de ponta a ponta e latência de serviço. O uso destas métricas de transação pode ajudar a identificar problemas de latência e/ou de rede do lado do cliente, ao determinar quanto tempo o tráfego do aplicativo passa em trânsito indo para e vindo do cliente.

A latência de ponta a ponta (SuccessE2ELatency) é o tempo total necessário para que uma transação execute uma viagem de ida e volta completa do cliente, pela rede, até o serviço Arquivos do Azure e de volta para o cliente.
A Latência de Serviço (SuccessServerLatency) é o tempo necessário para uma transação percorrer o caminho de ida e volta somente dentro do Azure Files. Isso não inclui nenhuma latência de cliente ou de rede.

A diferença entre os valores SuccessE2ELatency e SuccessServerLatency é a latência provavelmente causada pela rede e/ou pelo cliente.

É comum confundir a latência do cliente com a latência do serviço (nesse caso, o desempenho dos Arquivos do Azure). Por exemplo, se a latência do serviço estiver relatando latência baixa e o ponto a ponto estiver relatando latência muito alta para solicitações, isso sugere que todo o tempo é gasto em trânsito de e para o cliente, e não no serviço de Arquivos do Azure.

Além disso, como ilustra o diagrama, quanto mais longe você estiver do serviço, mais lento será a experiência de latência e mais difícil é atingir limites de escala de desempenho com qualquer serviço de nuvem. Isso é especialmente verdadeiro quando os Arquivos do Azure são acessados no local. Embora opções como o ExpressRoute sejam ideais para o local, elas ainda não correspondem ao desempenho de um aplicativo (computação + armazenamento) que está sendo executado exclusivamente na mesma região do Azure.

Dica

O uso de uma VM no Azure para testar o desempenho entre o local e o Azure é uma forma eficaz e prática de criar uma linha de base das funcionalidades de rede da conexão com o Azure. Circuitos do ExpressRoute ou gateways de VPN subdimensionados ou roteados incorretamente podem reduzir significativamente as cargas de trabalho em execução nos Arquivos do Azure.

Profundidade da fila

Profundidade da fila é o número de solicitações de E/S pendentes às quais um recurso de armazenamento pode atender. Como os discos usados pelos sistemas de armazenamento evoluíram de eixos HD (IDE, SATA e SAS) para dispositivos de estado sólido (SSD e NVMe), eles também evoluíram para dar suporte a uma profundidade de fila maior. Uma carga de trabalho que consiste em um só cliente que interage serialmente com um arquivo individual em um grande conjunto de dados é um exemplo de baixa profundidade da fila. Em contraste, uma carga de trabalho que suporta paralelismo com vários threads e vários arquivos pode facilmente atingir alta profundidade de fila. Como os Arquivos do Azure são um serviço de arquivo distribuído que abrange milhares de nós de cluster do Azure e foi projetado para executar cargas de trabalho em escala, recomendamos criar e testar cargas de trabalho com alta profundidade de fila.

A alta profundidade da fila pode ser obtida de várias maneiras diferentes em combinação com clientes, arquivos e threads. Para determinar a profundidade da fila da sua carga de trabalho, multiplique o número de clientes pelo número de arquivos e pelo número de threads (clientes * arquivos * threads = profundidade da fila).

A tabela abaixo ilustra as várias combinações que você pode usar para obter maior profundidade da fila. Embora você possa exceder a profundidade ideal da fila de 64, não recomendamos fazer isso. Você não verá mais ganhos de desempenho se fizer isso e correrá o risco de aumentar a latência devido à saturação de TCP.

Clientes	Arquivos	Tópicos	Profundidade da fila
1	1	1	1
1	1	2	2
1	2	2	4
2	2	2	oito
2	2	4	16
2	4	4	32
1	oito	oito	64
4	4	2	64

Dica

Para atingir limites de desempenho superiores, verifique se a carga de trabalho ou o teste de parâmetro de comparação tem vários threads com vários arquivos.

Aplicativos de thread único ou multithread

Arquivos do Azure é mais adequado para aplicativos multithread. A forma mais simples de compreender o impacto do multithreading sobre o desempenho de uma carga de trabalho é analisar o cenário por meio de entrada/saída (E/S). No exemplo a seguir, temos uma carga de trabalho que precisa copiar 10 mil arquivos pequenos o mais rápido possível em um compartilhamento de arquivo do Azure.

Esta tabela divide o tempo necessário (em milissegundos) para a criação de um só arquivo de 16 KiB em um compartilhamento de arquivo do Azure, com base em um aplicativo de thread único que faz gravações em tamanhos de bloco de 4 KiB.

Operação de E/S	Criar	Gravação de 4 KiB	Gravação de 4 KiB	Gravação de 4 KiB	Gravação de 4 KiB	Fechar	Total
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

Neste exemplo, seriam necessários aproximadamente 14 ms para criar um arquivo individual de 16 KiB das seis operações. Se um aplicativo monothread quiser mover 10 mil arquivos para um compartilhamento de arquivos do Azure, isso equivale a 140.000 ms (14 ms * 10.000) ou 140 segundos, porque cada arquivo é movido sequencialmente, um de cada vez. Tenha em mente que o tempo necessário para atender a cada solicitação é determinado principalmente pela proximidade do local da computação e do armazenamento entre si, conforme discutido na seção anterior.

Usando oito threads em vez de um, a carga de trabalho acima pode ser reduzida de 140.000 ms (140 segundos) para 17.500 ms (17,5 segundos). Conforme mostra a tabela abaixo, ao mover oito arquivos em paralelo em vez de um arquivo por vez, você pode mover o mesmo volume de dados em 87,5% menos tempo.

Operação de E/S	Criar	Gravação de 4 KiB	Gravação de 4 KiB	Gravação de 4 KiB	Gravação de 4 KiB	Fechar	Total
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 2	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 3	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 4	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 5	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 6	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 7	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 8	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

Compartilhar via

Reconhecimento e otimização do desempenho do compartilhamento de arquivo do Azure