Compreender os limites e padrões de chamadas

Aplica-se a: Programador

Utilize este artigo para planear padrões de chamadas do SharePoint Embedded antes de criar operações de conteúdo e contentor de alto volume. O SharePoint Embedded expressa o débito como unidades de recursos por minuto (um modelo normalizado de custo-pedido) em vez de como uma taxa fixa de pedidos por segundo; A secção Limites de taxa de API explica como traduzir unidades de recursos para uma taxa de pedido esperada.

Os limites marcados com * podem ser aumentados a pedido através do suporte da Microsoft ou do seu contacto de inclusão do SharePoint Embedded; planeie o limite predefinido e peça um aumento antes de o abordar na produção.

Limitar categorias

Os limites do SharePoint Embedded afetam:

  • *Contagens de tipos de contentor
  • *Contagens de contentores
  • Armazenamento por tipo de contentor e contentor
  • Arquivos e pastas
  • Permissões
  • Tamanho do arquivo
  • Contagem de versões
  • *Limites de taxa de API
  • *Pedidos por aplicação, contentor e utilizador

Observação

Estes limites podem ser alterados. Verifique os limites atuais antes de iniciar a produção.

Limites de tamanho

O SharePoint Embedded impõe os seguintes limites de tamanho.

Recurso Limite
Tipos de contentor que um inquilino parceiro pode criar 25*
Tipos de contentor que uma aplicação pode possuir 1
Contentores de um tipo de contentor por inquilino consumidor 100 k*
Armazenamento por tipo de contentor por inquilino de consumo 100 TB*
Files e pastas por contentor 30 M
Armazenamento por contentor 25 TB
Files e pastas com permissões de adição por contentor 5k
Tamanho do arquivo 250 GB
Contagem de versões por ficheiro 500 (Definição Predefinida dos Limites automáticos do Histórico de Versões)
Número de utilizadores partilhados por pasta ou ficheiro 5k

Um asterisco (*) indica um limite que pode pedir para aumentar.

Dos tipos de contentor que um inquilino cria, pode ser um tipo de contentor de avaliação gratuita para desenvolvimento e teste e os restantes são tipos de contentor padrão (faturados). Os novos inquilinos começam com uma predefinição mais baixa que pode ser levantada a pedido. Para obter detalhes de avaliação versus padrão, veja Criar e configurar um tipo de contentor.

Design para limites de tipo de contentor

Uma aplicação pode ser proprietária de um tipo de contentor.

Não modele cada cliente, projeto, área de trabalho ou utilizador como um tipo de contentor separado.

Utilize contentores para instâncias de armazenamento de aplicações no tipo de contentor.

Escolha um tipo de contentor para comportamento ao nível da aplicação, relação de acesso e responsabilidade de faturação.

Para o planeamento do tipo de contentor, veja Compreender os tipos de contentor e os contentores.

Conceção para limites de contentor

Os contentores fornecem o limite de armazenamento e segurança.

Planeie quantos contentores cada inquilino consumidor pode criar.

Conta dos contentores ativos e de qualquer ciclo de vida de contentor eliminado que possa afetar as quotas ou o armazenamento.

Mantenha os limites dos contentores alinhados com os requisitos de acesso, ciclo de vida e governação.

Estruturar para limites de permissão

O SharePoint Embedded permite até 5000 ficheiros e pastas com permissões de adição por contentor.

Evite conceber todos os ficheiros ou pastas para terem permissões exclusivas quando um modelo ao nível do contentor ou ao nível da pasta for suficiente.

Utilize a associação a contentores e funções sempre que possível.

Para obter os conceitos de permissão, veja Planear a autenticação e as permissões.

Respostas de limitação

Quando as aplicações atingirem os limites de serviço, o SharePoint Embedded pode devolver:

  • HTTP 429 Too Many Requests.
  • HTTP 503 Server Too Busy.

Ambas as respostas incluem um Retry-After cabeçalho.

O cabeçalho indica à aplicação quanto tempo deve esperar antes de repetir ou efetuar um novo pedido.

Importante

Os pedidos limitados contam para os limites de utilização. Se ignorar Retry-After, a sua aplicação pode causar mais limitação.

Orientação de repetição

Implemente a lógica de repetição que:

  • Deteta HTTP 429 e 503.
  • Lê o Retry-After cabeçalho.
  • Aguarda a duração especificada antes de tentar novamente.
  • Reduz a simultaneidade após a limitação.
  • Evita ciclos de repetição imediatos.
  • Evita picos de pedidos após um período de espera.

Utilize repetições limitadas e falhas persistentes do surface na telemetria de operações. Para obter orientações gerais sobre como lidar com respostas de limitação, veja Orientações de limitação do Microsoft Graph.

Orientações de simultaneidade

Reduza o número de pedidos simultâneos quando ocorre limitação.

Evite padrões de rajada que enviam muitos pedidos no mesmo instante.

Distribuir trabalho ao longo do tempo ao processar grandes conjuntos de contentores ou ficheiros.

Utilize filas ou trabalhos em segundo plano para suavizar o tráfego.

Priorize as operações visíveis pelo utilizador em vez da manutenção em segundo plano quando estiver perto dos limites.

Unidades de recursos da API

As APIs diferentes têm custos diferentes consoante a funcionalidade e a complexidade.

O custo é normalizado e expresso como unidades de recursos.

Os limites de taxa de API também são definidos com unidades de recursos.

Cada pedido custa unidades de recursos com base na sua complexidade:

Unidades de recurso por solicitação Operações
1 Consulta de item único, como obter item.
2 Consulta com vários itens, como listar subordinados, criar, atualizar, eliminar e carregar.
5 Todas as operações de recursos de permissão, incluindo $expand=permissions.

Observação

Os custos da unidade de recurso podem ser alterados.

Limites de taxa de API

O SharePoint Embedded impõe estes limites de taxa de API.

Recurso Limite
Pedidos por contentor 3k unidades de recursos por min
Pedidos por aplicação por inquilino 12 mil unidades de recursos por min*
Pedidos por utilizador 600 unidades de recursos por min

Um asterisco (*) indica um limite que pode pedir para aumentar.

Os limites da aplicação são definidos em unidades de recursos.

Os pedidos reais por minuto dependem das APIs que chama e do custo unitário do recurso.

Para estimar a taxa de pedidos, a média é de cerca de duas unidades de recursos por pedido e divide o limite de unidades de recursos da aplicação em dois.

Limitação da taxa de criação de contentores

Por inquilino consumidor e durante as horas de pico do inquilino, a criação de contentores está limitada a 5 novos contentores por segundo. Os pedidos para além deste limite são limitados por taxa. Fora das horas de ponta, os contentores podem ser criados a um ritmo mais rápido.

Custos da operação de permissão

As operações de recursos de permissão têm um custo unitário de recursos mais elevado.

As operações que incluem $expand=permissions estão listadas em cinco unidades de recursos.

Reduza a expansão desnecessária de permissões.

A cache de decisões derivadas de permissão apenas quando é segura para o seu modelo de segurança.

Atualize os dados de permissão quando ocorrem alterações de associação ou função.

Considerações sobre criação de batches

A criação de batches pode reduzir a sobrecarga do cliente, mas não remove os limites do serviço nem o impacto na faturação.

Conte cada operação subjacente quando estimar o consumo da unidade de recurso e o custo da transação.

Evite criar lotes que concentrem demasiado trabalho num contentor, aplicação, inquilino ou utilizador num curto intervalo de tempo.

Respeitar as respostas de limitação para operações em lotes de acordo com os detalhes de resposta devolvidos pela plataforma.

Considerações do desempenho

Conceção para:

  • Menos chamadas com permissões pesadas.
  • Simultaneidade previsível.
  • Sincronização incremental.
  • Recuo após limitação.
  • Separação do primeiro plano e do trabalho em segundo plano.
  • Equidade ao nível do inquilino para aplicações multi-inquilino.
  • Monitorização da taxa de pedidos, dos códigos de resposta e da latência.

Para obter o impacto na faturação das transações de API, veja Escolher um modelo de faturação.

Monitorização operacional

Controlar:

  • HTTP 429 e 503 taxas de resposta.
  • Contagens de repetição e durações de espera.
  • Operações de utilização intensiva de recursos.
  • Pedidos por aplicação, inquilino, utilizador e contentor.
  • Comprimento da fila da tarefa em segundo plano.
  • Crescimento do armazenamento por contentor e inquilino.
  • Frequência da operação de permissão.

Utilize estes sinais para otimizar a simultaneidade e identificar inquilinos ou fluxos de trabalho que precisem de alterações de estrutura.

Lista de verificação de planejamento

  • Confirme os limites de tamanho atuais antes do lançamento da produção.
  • Modelar contentores em vez de criar muitos tipos de contentor.
  • Estimar o armazenamento por contentor e por inquilino de consumo.
  • Calcule as contagens de ficheiros e pastas.
  • Evite permissões de aditivos desnecessárias.
  • Implemente o Retry-After processamento para 429 e 503.
  • Limite a simultaneidade e evite picos.
  • Estimar a utilização da unidade de recurso por tipo de operação.
  • Reduza as operações com permissões intensivas.
  • Monitorizar a limitação e a latência.
  • Inclua o impacto da faturação na estrutura da API.

Próximas etapas

Comece a criar com o Início Rápido: crie a sua primeira aplicação com o VS Code.

  • Last updated on