Performance and scalability checklist for Queue Storage

Microsoft has developed many proven practices for developing high-performance applications with Queue Storage. Esta lista de verificação identifica as principais práticas que os desenvolvedores podem seguir para otimizar o desempenho. Tenha essas práticas em mente ao projetar 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. For more information about Azure Storage scalability targets, see Scalability and performance targets for standard storage accounts and Scalability and performance targets for Queue Storage.

Lista de verificação

This article organizes proven practices for performance into a checklist you can follow while developing your Queue Storage application.

Metas de escalabilidade

If your application approaches or exceeds any of the scalability targets, it might encounter increased transaction latencies or throttling. When Azure Storage throttles your application, the service begins to return 503 (Server Busy) or 500 (Operation Timeout) error codes. Evitar esses erros permanecendo dentro dos limites das metas de escalabilidade é uma parte importante para melhorar o desempenho do seu aplicativo.

For more information about scalability targets for Queue Storage, see Azure Storage scalability and performance targets.

Número máximo de contas de armazenamento

If you're approaching the maximum number of storage accounts permitted for a particular subscription/region combination, are you using multiple storage accounts to shard to increase ingress, egress, I/O operations per second (IOPS), or capacity? Nesse cenário, a Microsoft recomenda que você aproveite os limites aumentados para contas de armazenamento para 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 limites maiores para sua conta de armazenamento.

Capacidade e metas de transação

Se seu aplicativo estiver se aproximando das metas de escalabilidade para uma única conta de armazenamento, considere adotar uma das seguintes abordagens:

• If the scalability targets for queues are insufficient for your application, then use multiple queues and distribute messages across them.
• Reconsidere a carga de trabalho que faz com que seu aplicativo se aproxime ou exceda a meta de escalabilidade. Você pode projetá-lo de forma diferente para usar menos largura de banda ou capacidade, ou menos transações?
• Se seu aplicativo precisar exceder um dos destinos de escalabilidade, crie várias contas de armazenamento e particione os dados do aplicativo entre essas várias contas de armazenamento. Se você usar esse padrão, certifique-se de projetar seu aplicativo para que possa adicionar mais contas de armazenamento no futuro para balanceamento de carga. As próprias contas de armazenamento não têm nenhum custo além do seu uso em termos de dados armazenados, transações feitas ou dados transferidos.
• Se seu aplicativo estiver se aproximando dos destinos de largura de banda, considere compactar dados no lado do 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 da rede, também pode ter efeitos negativos no desempenho. Avalie o impacto no desempenho dos requisitos de processamento adicionais para compactação e descompactação de dados no lado do cliente. Keep in mind that storing compressed data can make troubleshooting more difficult because it might be more challenging to view the data using standard tools.
• If your application is approaching the scalability targets, then make sure that you're using an exponential backoff for retries. É melhor tentar evitar atingir as metas de escalabilidade implementando as recomendações descritas neste artigo. However, using an exponential backoff for retries prevents your application from retrying rapidly, which could make throttling worse. For more information, see the Timeout and Server Busy errors section.

Ligação em rede

As restrições de rede física do aplicativo podem ter um impacto significativo no desempenho. As seções a seguir descrevem algumas das limitações que os usuários podem encontrar.

Capacidade de rede do cliente

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

Throughput

Em relação à largura de banda, o problema é muitas vezes as capacidades do cliente. Instâncias maiores do Azure têm NICs com maior capacidade, portanto, você deve considerar o uso de uma instância maior ou mais VMs se precisar de limites de rede mais altos de uma única máquina. If you're accessing Azure Storage from an on-premises application, then the same rule applies: understand the network capabilities of the client device and the network connectivity to the Azure Storage location and either improve them as needed or design your application to work within their capabilities.

Qualidade do link

Como em qualquer uso de rede, tenha em mente que as condições de rede que resultam em erros e perda de pacotes retardam a taxa de transferência efetiva. Using Wireshark or Network Monitor might help in diagnosing this issue.

Localização

Em qualquer ambiente distribuído, colocar o cliente perto do servidor proporciona o melhor desempenho. Para acessar o Armazenamento do Azure com a menor latência, o melhor local para seu cliente é dentro da mesma região do Azure. For example, if you have an Azure web app that uses Azure Storage, then locate them both within a single region, such as West US or Southeast Asia. O alojamento conjunto de recursos reduz a latência e o custo, uma vez que o uso da largura de banda numa única região é gratuito.

If client applications access Azure Storage but aren't hosted within Azure, such as mobile device apps or on-premises enterprise services, then locating the storage account in a region near to those clients might reduce latency. Se seus 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 JavaScript em execução no navegador da Web de um usuário ou em um aplicativo de celular para acessar dados no Armazenamento do Azure. Uma abordagem é criar um aplicativo de serviço que atue como um proxy. O dispositivo do usuário é autenticado com o serviço, que, por sua vez, autoriza o acesso aos recursos do Armazenamento do Azure. Desta forma, pode evitar expor as chaves da sua conta de armazenamento em dispositivos inseguros. No entanto, essa abordagem coloca uma sobrecarga significativa no aplicativo de serviço, porque todos os dados transferidos entre o dispositivo do usuário e o Armazenamento do Azure devem passar pelo aplicativo de serviço.

Você pode evitar usar um aplicativo de serviço como um proxy para o Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS). Usando o SAS, você pode habilitar o dispositivo do usuário para fazer solicitações diretamente ao Armazenamento do Azure usando um token de acesso limitado. Por exemplo, se um usuário quiser carregar uma foto para seu aplicativo, seu aplicativo de serviço poderá gerar uma SAS e enviá-la para o dispositivo do usuário. O token SAS pode conceder permissão para gravar em um recurso de Armazenamento do Azure por um intervalo de tempo especificado, após o qual o token SAS expira. Para obter mais informações sobre SAS, consulte Conceder acesso limitado aos recursos do Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS).

Normalmente, um navegador da Web não permite que 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 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 compartilhamento de recursos entre origens (CORS) é um recurso do navegador que permite que o domínio de destino comunique ao navegador que confia nas solicitações originadas no domínio de origem.

Por exemplo, suponha que um aplicativo Web em execução no Azure faça uma solicitação de um recurso para uma conta de 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 qualquer um dos serviços de Armazenamento do Azure para comunicar ao navegador da Web que as solicitações do domínio de origem são confiáveis pelo Armazenamento do Azure. Para obter mais informações sobre CORS, consulte Suporte de compartilhamento de recursos entre origens (CORS) para o Armazenamento do Azure.

Tanto o SAS quanto o CORS podem ajudá-lo a evitar cargas desnecessárias em seu aplicativo Web.

Configuração do .NET

Para projetos que usam o .NET Framework, esta seção lista algumas definições de configuração rápida que você pode usar para fazer melhorias significativas de desempenho. Se você estiver usando um idioma diferente do .NET, verifique se conceitos semelhantes se aplicam no idioma escolhido.

Aumentar o 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 de conexão padrão (que geralmente é 2 em um ambiente de cliente ou 10 em um ambiente de servidor) para 100. Normalmente, você deve definir o valor para aproximadamente o número de threads usados pelo seu aplicativo. Defina o limite de conexão antes de abrir qualquer conexão.

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

Para saber mais sobre os limites do pool de conexões no .NET Framework, consulte Limites do pool de conexões do .NET Framework e o novo SDK do Azure para .NET.

Para outras linguagens de programação, consulte a documentação para determinar como definir o limite de conexão.

Aumentar o número mínimo de threads

If you're using synchronous calls together with asynchronous tasks, you might want to increase the number of threads in the thread pool:

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

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

Paralelismo ilimitado

Embora o paralelismo possa ser ótimo para o desempenho, tenha cuidado ao usar paralelismo ilimitado, o que significa que não há limite imposto ao número de threads ou solicitações paralelas. Certifique-se de limitar as solicitações paralelas para carregar ou baixar dados, para acessar várias partições na mesma conta de armazenamento ou para acessar vários itens na mesma partição. Se o paralelismo não for limitado, a sua aplicação poderá exceder os recursos do dispositivo cliente ou os objetivos de escalabilidade da conta de armazenamento, resultando em latências maiores e estrangulamento.

Bibliotecas e ferramentas de clientes

Para obter o melhor desempenho, use sempre as bibliotecas de cliente e as ferramentas mais recentes fornecidas pela Microsoft. As bibliotecas de cliente do Armazenamento do Azure estão disponíveis para vários idiomas. O Armazenamento do Azure também dá suporte ao PowerShell e à CLI do Azure. A Microsoft desenvolve ativamente essas bibliotecas e ferramentas de cliente com o desempenho em mente, mantém-nas atualizadas com as versões de serviço mais recentes e garante que elas lidem com muitas das práticas de desempenho comprovadas internamente. For more information, see the Azure Storage reference documentation.

Handle service errors

O Armazenamento do Azure retorna um erro quando o serviço não pode processar uma solicitação. Understanding the errors that might be returned by Azure Storage in a given scenario is helpful for optimizing performance.

Timeout and Server Busy errors

O Armazenamento do Azure pode limitar seu aplicativo se ele se aproximar dos limites de escalabilidade. Em alguns casos, o Armazenamento do Azure pode não conseguir lidar com uma solicitação devido a alguma condição transitória. In both cases, the service might return a 503 (Server Busy) or 500 (Timeout) error. Esses erros também podem ocorrer se o serviço estiver reequilibrando partições de dados para permitir uma taxa de transferência mais alta. O aplicativo cliente normalmente deve tentar novamente a operação que causa um desses erros. No entanto, se o Armazenamento do Azure estiver limitando seu aplicativo porque está excedendo as metas de escalabilidade, ou mesmo se o serviço não pôde atender à solicitação por algum outro motivo, novas tentativas agressivas podem piorar o problema. Using an exponential back off retry policy is recommended, and the client libraries default to this behavior. Por exemplo, seu aplicativo pode tentar novamente após 2 segundos, depois 4 segundos, depois 10 segundos, depois 30 segundos e, em seguida, desistir completamente. In this way, your application significantly reduces its load on the service, rather than exacerbating behavior that could lead to throttling.

Connectivity errors can be retried immediately, because they aren't the result of throttling and are expected to be transient.

Erros não repetitivos

As bibliotecas de cliente lidam com repetições, com conhecimento de quais erros podem ser repetidos e quais não. No entanto, se você estiver chamando a API REST do Armazenamento do Azure diretamente, há alguns erros que você não deve tentar novamente. For example, a 400 (Bad Request) error indicates that the client application sent a request that couldn't be processed because it wasn't in the expected form. Reenviar essa solicitação resulta sempre na mesma resposta, portanto, não adianta tentar novamente. Se você estiver chamando a API REST do Armazenamento do Azure diretamente, esteja ciente de possíveis erros e se eles devem ser repetidos.

Para obter mais informações sobre códigos de erro do Armazenamento do Azure, consulte Códigos de status e de erro.

Disable Nagle's algorithm

O algoritmo de Nagle é amplamente implementado em redes TCP/IP como um meio de melhorar o desempenho da rede. No entanto, não é ideal em todas as circunstâncias (como ambientes altamente interativos). Nagle's algorithm has a negative impact on the performance of requests to Azure Table Storage, and you should disable it if possible.

Tamanho da mensagem

Queue performance and scalability decrease as message size increases. Put only the information the receiver needs in a message.

Batch retrieval

You can retrieve up to 32 messages from a queue in a single operation. Batch retrieval can reduce the number of round trips from the client application, which is especially useful for environments, such as mobile devices, with high latency.

Queue polling interval

Most applications poll for messages from a queue, which can be one of the largest sources of transactions for that application. Select your polling interval wisely: polling too frequently could cause your application to approach the scalability targets for the queue. However, at 200,000 transactions for $0.01 (at the time of writing), a single processor polling once every second for a month would cost less than 15 cents so cost isn't typically a factor that affects your choice of polling interval.

For up-to-date cost information, see Azure Storage pricing.

Perform an update message operation

You can perform an update message operation to increase the invisibility timeout or to update the state information of a message. This approach can be a more efficient than having a workflow that passes a job from one queue to the next, as each step of the job is completed. Your application can save the job state to the message and then continue working, instead of requeuing the message for the next step of the job every time a step completes. Keep in mind that each update message operation counts towards the scalability target.

Arquitetura de aplicativos

Use queues to make your application architecture scalable. The following lists some ways you can use queues to make your application more scalable:

• You can use queues to create backlogs of work for processing and smooth out workloads in your application. For example, you could queue up requests from users to perform processor intensive work such as resizing uploaded images.
• You can use queues to decouple parts of your application so that you can scale them independently. For example, a web front end could place survey results from users into a queue for later analysis and storage. You could add more worker role instances to process the queue data as required.

Próximos passos

• Scalability and performance targets for Queue Storage
• Metas de escalabilidade e desempenho para contas de armazenamento padrão
• Códigos de status e de erro