Lista de verificação de desempenho e escalabilidade do Armazenamento de Filas

A Microsoft desenvolveu várias práticas comprovadas para desenvolver aplicativos de alto desempenho com o Armazenamento de Filas. Essa lista de verificação identifica as principais práticas que os desenvolvedores podem seguir para otimizar o desempenho. Tenha essas práticas em mente enquanto estiver projetando seu aplicativo e durante todo o processo.

O Armazenamento do Azure tem metas de escalabilidade e desempenho para capacidade, taxa de transação e largura de banda. Para obter mais informações sobre as metas de escalabilidade do Armazenamento do Azure, confira Metas de escalabilidade e desempenho das contas de armazenamento Standard e Metas de escalabilidade e desempenho do Armazenamento de Filas.

Lista de verificação

Este artigo organiza as práticas comprovadas de desempenho em uma lista de verificação que você pode seguir enquanto desenvolve seu aplicativo do Armazenamento de Filas.

Metas de escalabilidade

Se o seu aplicativo se aproximar ou ultrapassar alguma das metas de escalabilidade, pode haver aumento da latência e restrição das transações. Quando o Armazenamento do Azure limita seu aplicativo, o serviço começa a retornar os códigos de erro 503 (Server Busy) ou 500 (Operation Timeout). Evitar esses erros mantendo-se dentro dos limites dos destinos de escalabilidade é uma parte importante do aprimoramento do desempenho do seu aplicativo.

Para obter mais informações sobre as metas de escalabilidade do Armazenamento de Filas, confira Metas de escalabilidade e desempenho do Armazenamento do Azure.

Número máximo de contas de armazenamento

Se você está se aproximando do número máximo de contas de armazenamento permitidas para uma combinação de assinatura/região específica, você está usando várias contas de armazenamento para fragmentar a fim de aumentar a entrada, a saída, as IOPS (operações de E/S por segundo) ou a capacidade? Nesse cenário, a Microsoft recomenda que você use maiores limites para contas de armazenamento a fim de reduzir o número de contas de armazenamento necessárias para sua carga de trabalho, se possível. Entre em contato com o Suporte do Azure para solicitar maiores limites para sua conta de armazenamento.

Metas de capacidade e de transação

Se seu aplicativo estiver lidando com metas de escalabilidade de uma única conta de armazenamento, você pode adotar uma destas abordagens:

• Se as metas de escalabilidade para filas forem insuficientes para seu aplicativo, use várias filas e distribua mensagens entre elas.
• Repensar a carga de trabalho que faz com que o aplicativo se aproxime da meta de escalabilidade ou a ultrapasse. Você pode alterar o aplicativo para que ele use menos largura de banda, menos capacidade ou menos transações?
• Se o aplicativo ultrapassar uma das metas de escalabilidade propositalmente, crie diversas contas de armazenamento e particione os dados do seu aplicativo nessas contas. Se você usar esse padrão, crie o aplicativo de forma que seja possível adicionar mais contas de armazenamento posteriormente, para balancear a carga. O único custo das contas de armazenamento é o uso dos dados armazenados, das transações feitas ou dos dados transferidos.
• Se o aplicativo estiver atingindo as metas de largura de banda, considere compactar os dados no cliente para reduzir a largura de banda necessária para enviar os dados para o Armazenamento do Azure. Embora a compactação de dados possa economizar largura de banda e melhorar o desempenho de rede, ela também pode ter efeitos negativos sobre o desempenho. Avalie o impacto de desempenho dos requisitos de processamento adicionais para compactação e descompactação de dados no lado do cliente. Tenha em mente que armazenar dados compactados pode dificultar a solução de problemas, porque pode ser mais desafiador exibir os dados usando ferramentas padrão.
• Se o seu aplicativo estiver se aproximando das metas de escalabilidade, certifique-se de que esteja usando uma retirada exponencial para novas tentativas. É melhor tentar evitar alcançar as metas de escalabilidade implementando as recomendações descritas neste artigo. No entanto, o uso de um backoff exponencial para novas tentativas impede que seu aplicativo tente novamente com rapidez, o que pode piorar a limitação. Para obter mais informações, confira a seção Erros de Tempo Limite e Servidor Ocupado.

Rede

As restrições físicas da rede do aplicativo podem ter um impacto considerável no desempenho. As seções a seguir descrevem algumas das limitações que os usuários podem enfrentar.

Funcionalidade da rede do cliente

A largura de banda e a qualidade do link da rede desempenham funções importantes no desempenho do aplicativo, conforme descrito nas seções a seguir.

Produtividade

No caso da largura de banda, muitas vezes o problema está relacionado às funcionalidades do cliente. As instâncias maiores do Azure têm NICs com mais capacidade. Por isso, você deve usar uma instância maior ou mais VMs se precisar de limites de rede mais altos em um único computador. Se você estiver acessando o Armazenamento do Microsoft Azure a partir de um aplicativo local, a mesma regra se aplica: entenda os recursos de rede do dispositivo cliente e a conectividade de rede com o local de Armazenamento do Azure e aprimore-os conforme necessário ou projete seu aplicativo para funcionar dentro das capacidades deles.

Qualidade do link

Como em qualquer uso de rede, lembre-se de que as condições de rede que resultam em erros e perda de pacotes reduzem a taxa de transferência efetiva. O uso do Wireshark ou do Monitor de Rede pode ajudar a diagnosticar esse problema.

Location

Em todos os ambientes, colocar o cliente próximo ao servidor proporciona o melhor desempenho. Para acessar o armazenamento do Azure com o mínimo de latência, o melhor local para o cliente é a região na qual o Azure se encontra. Por exemplo, se você tiver um aplicativo Web do Azure que usa o Armazenamento do Azure, localize-os em uma só região, como o Oeste dos EUA ou o Sudeste da Ásia. Colocalizar recursos reduz a latência e o custo, pois o uso de largura de banda em uma única região é gratuito.

Se os aplicativos cliente acessarem o Armazenamento do Microsoft Azure, mas não estiverem hospedados no Azure, como aplicativos de dispositivo móvel ou serviços corporativos locais, a localização da conta de armazenamento em uma região próxima a esses clientes poderá reduzir a latência. Se os clientes estiverem amplamente distribuídos (por exemplo, alguns na América do Norte e outros na Europa), considere usar uma conta de armazenamento por região. Essa abordagem é mais fácil de implementar se os dados que o aplicativo armazena forem específicos para usuários individuais e não exigirem a replicação de dados entre contas de armazenamento.

SAS e CORS

Suponha que você precise autorizar um código, como o JavaScript que está sendo executado no navegador da Web de um usuário ou em um aplicativo de celular, a acessar dados no armazenamento do Azure. Uma abordagem é criar um aplicativo de serviço que funcione como um proxy. O dispositivo do usuário é autenticado no serviço que, por sua vez, autoriza o acesso aos recursos do Armazenamento do Azure. Dessa forma, você pode evitar a exposição das chaves de conta de armazenamento em dispositivos que não são seguros. No entanto, essa abordagem gera uma sobrecarga significativa no aplicativo do serviço, porque todos os dados transferidos entre o dispositivo do usuário e o Armazenamento do Azure devem passar pelo aplicativo do serviço.

Você pode evitar usar um aplicativo de serviço como um proxy para o Armazenamento do Azure usando SAS (assinaturas de acesso compartilhado). Usando SAS, você pode permitir que o dispositivo do seu usuário faça solicitações diretamente ao Armazenamento do Azure usando um token de acesso limitado. Por exemplo, se um usuário desejar fazer upload de uma foto para seu aplicativo, seu aplicativo de serviço poderá gerar uma SAS e enviá-la ao dispositivo do usuário. O token SAS pode conceder permissão para gravar em um recurso do Armazenamento do Azure durante um intervalo especificado de tempo; depois disso, o token SAS expirará. Para obter mais informações sobre SAS, confira Conceder acesso limitado a recursos de Armazenamento do Azure usando SAS (assinaturas de acesso compartilhado).

Normalmente, um navegador da Web não permite que o JavaScript em uma página hospedada por um site em um domínio execute determinadas operações, como operações de gravação, em outro domínio. Conhecida como a política de mesma origem, essa política impede que um script mal-intencionado em uma página obtenha acesso a dados em outra página da Web. No entanto, a política de mesma origem pode ser uma limitação ao criar uma solução na nuvem. O CORS (compartilhamento de recurso entre origens) é um recurso do navegador que permite que o domínio de destino se comunique com o navegador ao qual ele confia as solicitações que se originam no domínio de origem.

Por exemplo, suponha que um aplicativo Web em execução no Azure faça uma solicitação para um recurso para uma conta do Armazenamento do Azure. O aplicativo Web é o domínio de origem e a conta de armazenamento é o domínio de destino. Você pode configurar o CORS para que qualquer um dos serviços do Armazenamento do Azure se comunique com o navegador da Web cujas solicitações do domínio de origem têm a confiança do Armazenamento do Azure. Para obter mais informações sobre o CORS, confira Suporte ao CORS (compartilhamento de recurso entre origens) para o Armazenamento do Azure.

SAS e CORS podem ajudar você a evitar uma carga desnecessária em seu aplicativo Web.

Configuração do .NET

Para projetos que usam o .NET Framework, esta seção lista algumas definições de configurações rápidas que podem ser usadas para melhorar significativamente o desempenho. Se estiver usando uma linguagem diferente do .NET, verifique se conceitos semelhantes se aplicam à linguagem escolhida.

Aumentar limite de conexão padrão

Para projetos que usam o .NET Framework, você pode usar o código a seguir para aumentar o limite da conexão padrão (que geralmente é de dois em um ambiente de cliente ou dez em um ambiente de servidor) para 100. Normalmente, você deve definir o valor para aproximadamente igual ao número de threads utilizados pelo seu aplicativo. Defina o limite da conexão antes de abrir conexões.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

Para saber mais sobre os limites do pool de conexão no .NET Framework, confira Limites do Pool de Conexão do .NET Framework e o novo SDK do Azure para .NET.

Para outras linguagens de programação, confira a documentação para verificar como definir o limite da conexão.

Aumentar o número mínimo de threads

Se você estiver usando chamadas síncronas junto com tarefas assíncronas, convém aumentar o número de threads no pool de threads:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)  

Para obter mais informações, confira o método ThreadPool.SetMinThreads.

Paralelismo não associado

Embora o paralelismo possa ser ótimo para o desempenho, tenha cuidado ao usar o paralelismo ilimitado, o que significa que não há limite imposto ao número de threads ou solicitações paralelas. Limite as solicitações paralelas para fazer upload ou baixar dados, para acessar várias partições na mesma conta de armazenamento ou acessar vários itens na mesma partição. Se o paralelismo não estiver associado, o aplicativo poderá ultrapassar as funcionalidades do dispositivo cliente ou as metas de escalabilidade da conta de armazenamento, o que resultará em limitação e latências mais longas.

Bibliotecas de cliente e ferramentas

Para obter o melhor desempenho, sempre use as bibliotecas de cliente e ferramentas mais recentes fornecidas pela Microsoft. As bibliotecas de cliente do Armazenamento do Microsoft Azure estão disponíveis para várias linguagens. O Armazenamento do Azure também dá suporte ao PowerShell e à CLI do Azure. A Microsoft desenvolve ativamente essas ferramentas e bibliotecas de cliente pensando no desempenho, os mantém atualizados com as versões de serviço mais recentes e verifica se eles lidam com muitas práticas de desempenho comprovadas internamente. Para obter mais informações, confira a documentação de referência do Armazenamento do Azure.

Manipular erros de serviço

O Armazenamento do Microsoft Azure retorna um erro quando o serviço não pode processar uma solicitação. Entender os erros que podem ser retornados pelo Armazenamento do Azure em um determinado cenário é útil para otimizar o desempenho.

Erros de Tempo Limite e Servidor Ocupado

O Armazenamento do Microsoft Azure poderá restringir seu aplicativo se ele se aproximar dos limites de escalabilidade. Em alguns casos, o Armazenamento do Microsoft Azure pode ser incapaz de lidar com uma solicitação devido a algumas condições transitórias. Em ambos os casos, o serviço poderá retornar um erro 503 (Server Busy) ou 500 (Timeout). Esses erros também poderão ocorrer se o serviço estiver reequilibrando partições de dados para permitir uma taxa de transferência mais alta. Normalmente, o aplicativo cliente deve repetir a operação que gera um erro desses erros. No entanto, se o Armazenamento do Microsoft Azure estiver limitando seu aplicativo porque ele está excedendo as metas de escalabilidade, ou mesmo se o serviço não conseguiu atender à solicitação por algum outro motivo, novas tentativas agressivas podem piorar o problema. O uso de uma política de repetição de retirada exponencial é recomendado e o padrão das bibliotecas de cliente é esse comportamento. Por exemplo, o aplicativo pode fazer uma nova tentativa em 2 segundos, 4 segundos, 10 segundos e 30 segundos para então abandonar o processo. Dessa forma, seu aplicativo reduz significativamente sua carga sobre o serviço, em vez de exacerbar o comportamento que poderia causar a limitação.

Os erros de conectividade podem ser repetidos imediatamente, porque não são o resultado de limitação e espera-se que sejam transitórios.

Erros sem nova tentativa

As bibliotecas de cliente manipulam as novas tentativas com um reconhecimento de quais erros podem ser repetidos e quais não. No entanto, se você estiver chamando a API REST do Armazenamento do Microsoft Azure diretamente, há alguns erros que não devem ser repetidos. Por exemplo, um erro 400 (Bad Request) indica que o aplicativo cliente enviou uma solicitação que não pôde ser processada porque não estava no formato esperado. Reenviar essa solicitação resulta na mesma resposta todas as vezes, portanto, não faz sentido tentar novamente. Se você estiver chamando a API REST de Armazenamento do Microsoft Azure diretamente, esteja ciente de possíveis erros e se eles devem ser repetidos.

Para obter mais informações sobre os códigos de erro do Armazenamento do Azure, confira Status e códigos de erro.

Desabilitar o algoritmo de Nagle

O algoritmo de Nagle é implementado largamente em redes TCP/IP como meio de melhorar o desempenho das redes. No entanto, isso não é ideal em todas as circunstâncias (como em ambientes altamente interativos). O algoritmo de Nagle tem um impacto negativo sobre o desempenho de solicitações para o Armazenamento de Tabelas do Azure e você deve desabilitá-lo, se possível.

Tamanho da mensagem

O desempenho de fila e a escalabilidade diminuem conforme o tamanho da mensagem aumenta. Coloque apenas as informações de que o receptor precisa em uma mensagem.

Recuperação em lote

Você pode recuperar até 32 mensagens de uma fila em uma única operação. A recuperação em lote pode reduzir o número de viagens de ida e volta do aplicativo cliente, o que é especialmente útil para ambientes, como dispositivos móveis, com alta latência.

Intervalo de sondagem de fila

A maioria dos aplicativos de sondagem para mensagens de uma fila, pode ser uma das principais fontes de transações para o aplicativo. Selecione o intervalo de sondagem com sabedoria: a sondagem muito frequente pode fazer com que seu aplicativo se aproxime das metas de escalabilidade para a fila. No entanto, em 200.000 transações para US $0,01 (no momento da gravação), um único processador sondando uma vez por segundo em um mês custaria menos de 15 centavos, assim o custo de sondagem não é normalmente um fator que afeta sua opção de intervalo de sondagem.

Para obter informações atualizadas sobre custos, confira Preços do Armazenamento do Azure.

Executar uma operação de atualização de mensagem

Você pode executar uma operação de atualização de mensagem para aumentar o tempo limite de invisibilidade ou para atualizar as informações de estado de uma mensagem. Essa abordagem pode ser mais eficiente do que ter um fluxo de trabalho que transmite um trabalho de uma fila para a próxima, conforme cada etapa do trabalho é concluída. Seu aplicativo pode salvar o estado do trabalho para a mensagem e continuar trabalhando, em vez de enfileirar a mensagem novamente para a próxima etapa do trabalho cada vez que uma etapa é concluída. Tenha em mente que cada operação de atualização de mensagem é contada para a meta de escalabilidade.

Arquitetura do aplicativo

Use filas para tornar a arquitetura do seu aplicativo escalonável. A seguir temos algumas maneiras de usar filas para que seu aplicativo seja mais escalonável:

• Você pode usar as filas para criar listas de pendências de trabalho para processamento e suavização das cargas de trabalho no seu aplicativo. Por exemplo, você pode colocar na fila as solicitações dos usuários para execução de trabalhos que requerem trabalho muito intenso do processador, como o redimensionamento das imagens carregadas.
• Você pode usar as filas para desassociar parte do aplicativo, a fim de poder escaloná-las de forma independente. Por exemplo, um front-end da Web pode colocar os resultados de pesquisa dos usuários em uma fila para análise posterior e armazenamento. Você pode adicionar mais instâncias de função de trabalho para processar os dados da fila conforme necessário.

Próximas etapas

• Metas de escalabilidade e desempenho do Armazenamento de Filas
• Metas de escalabilidade e desempenho das contas de Armazenamento Standard
• Status e códigos de erro