Evitar ficar limitado ou bloqueado no SharePoint Online

  • Artigo

Saiba mais sobre a limitação no SharePoint Online e saiba como evitar ser limitado ou bloqueado.

Significa este som está familiarizado? Você está executando um processo CSOM - por exemplo, para migrar os arquivos SharePoint Online -, mas você continua limitado. Ou, pior ainda, você seja bloqueado. O que está acontecendo e o que você pode fazer para torná-la a parar?

O que é limitação?

SharePoint Online usa a limitação para manter o melhor desempenho e confiabilidade do serviço SharePoint Online. A limitação limita o número de chamadas à API ou operações em uma janela de tempo para evitar o uso excessivo de recursos.

O que acontece quando você obter limitadas em SharePoint Online ?

Quando os limites de uso são excedidos, o SharePoint Online limita as solicitações adicionais desse cliente por um curto período.

Para solicitações executadas pelo usuário diretamente no navegador, o SharePoint Online o redireciona para a página de informações de limitação, e as solicitações falham.

Para solicitações feitas por um aplicativo, incluindo chamadas do Microsoft Graph, CSOM ou REST, o SharePoint Online retorna HTTP status código 429 ("Solicitações demais") ou 503 ("Servidor Muito Ocupado") e as solicitações falharão.

  • HTTP 429 indica que o aplicativo de chamada enviou muitas solicitações em uma janela de tempo e excedeu um limite predeterminado.
  • HTTP 503 indica que o serviço não está pronto para lidar com a solicitação. A causa comum é que o serviço está enfrentando picos de carga mais temporários do que o esperado.

Em ambos os casos, um cabeçalho Retry-After é incluído na resposta que indica quanto tempo o aplicativo de chamada deve aguardar antes de tentar novamente ou fazer uma nova solicitação. As solicitações limitadas contam para os limites de uso, portanto, a falha ao respeitar o Retry-After pode resultar em mais limitação.

Se o aplicativo incorreto continuar excedendo os limites de uso, o SharePoint Online poderá bloquear completamente o aplicativo ou padrões de solicitação específicos do aplicativo; nesse caso, o aplicativo manterá o código de status HTTP 503 e a Microsoft notificará o locatário do bloco no Centro de Mensagens do Office 365.

Limitação do Usuário

A limitação limita o número de chamadas e operações coletivamente feitas por aplicativos em nome de um usuário para evitar o uso excessivo de recursos.

Dito isso, é raro um usuário ser limitado no SharePoint Online. O serviço é robusto e projetado para lidar com grandes volumes. Se você for limitado, 99% do tempo será devido ao código personalizado, como web parts personalizadas, exibição de lista complexa e consultas ou aplicativos personalizados executados pelos usuários. Isso não significa que não haja outras maneiras de ser limitados, mas elas são menos comuns. Por exemplo, um usuário que sincroniza uma grande quantidade de dados em 10 computadores ao mesmo tempo pode disparar a limitação.

Limitação do aplicativo

Além da limitação por conta de usuário, os limites também são aplicados a cada aplicativo em um locatário.

Cada aplicativo tem seus próprios limites em um locatário, que se baseiam no número de licenças compradas por organização (consulte os planos listados nos Limites do SharePoint para licenças incluídas). Cada solicitação que um aplicativo faz em todos os pontos de extremidade da API, incluindo Microsoft Graph, CSOM e REST, conta para o uso do aplicativo.

O SharePoint fornece várias APIs. As APIs diferentes têm custos diferentes, dependendo da complexidade da API. O custo das APIs é normalizado pelo SharePoint e expresso por unidades de recurso. Os limites do aplicativo também são definidos usando unidades de recurso.

A tabela a seguir define os limites de unidade de recurso para um aplicativo em um locatário:

Contagem de licenças 0 – 1 mil 1 mil – 5 mil 5 mil a 15 mil 15 mil a 50 mil Mais de 50 mil
Aplicativo de 1 minuto 1.200 2.400 3.600 4.800 6.000
Aplicativo diariamente 1.200.000 2.400.000 3.600.000 4.800.000 6.000.000

Observação

Reservamo-nos o direito de alterar os limites da unidade de recurso.

Em termos de custos de API, as APIs do Microsoft Graph têm um custo unitário de recurso predeterminado por solicitação:

Unidades de recurso por solicitação Operações
1
  • Consulta de item único, como obter item
  • Delta com um token
    		•
    2
  • Consulta de vários itens, como listar filhos, exceto delta com um token
  • Criar, atualizar, excluir e carregar
    		•
    5
  • Todas as operações de recurso de permissão, incluindo $expand=permissões
    		•

    Observação

    Reservamo-nos o direito de alterar o custo da unidade de recurso da API.

    Delta com um token é a maneira mais eficiente de examinar o conteúdo no SharePoint e falamos mais em detalhes sobre as melhores práticas para verificar aplicativos. Para ajudar os aplicativos que seguem as diretrizes, reduzimos o custo da unidade de recurso de solicitações delta com um token para uma unidade de recurso, embora seja uma consulta de vários itens. A solicitação delta sem um token é considerada uma consulta de vários itens e custa 2 unidades de recurso por solicitação.

    No envio em lote, as solicitações em um lote são avaliadas individualmente por unidades de recurso.

    O CSOM e o REST não têm um custo de unidade de recurso predeterminado e geralmente consomem mais unidades de recursos do que as APIs do Microsoft Graph para obter a mesma funcionalidade. Além dos limites de unidade de recurso, o CSOM e o REST também estão sujeitos a outros limites de recursos internos, portanto, se os aplicativos chamarem CSOM e REST, eles poderão ter mais limitação do que os limites descritos neste documento. Recomendamos que você escolha APIs do Microsoft Graph em vez de APIs REST e CSOM quando possível.

    Como os limites de aplicativo estão em unidades de recursos, a taxa de solicitação real, como solicitações por minuto, depende da escolha da API do aplicativo e do custo da unidade de recurso de API correspondente. Em geral, você pode estimar a taxa de solicitação usando uma média de 2 unidades de recursos por solicitação e dividir os limites da unidade de recursos em 2 para obter a taxa de solicitação estimada.

    Embora cada aplicativo tenha seus próprios limites em um locatário e permitamos que os locatários executem mais de um aplicativo, vários aplicativos em execução no mesmo locatário compartilham o mesmo bucket de recursos e, em ocorrências raras, podem causar limitação de taxa quando muitos aplicativos enviam solicitações no momento.

    Como lidar com a limitação?

    Veja abaixo um resumo rápido das práticas recomendadas para lidar com a limitação:

    • Reduzir o número de solicitações simultâneas
    • Evitar picos de solicitação
    • Escolha APIs do Microsoft Graph em vez de APIs REST e CSOM quando possível
    • Usar os cabeçalhos HTTP Retry-After e RateLimit
    • Decore seu tráfego para sabermos quem você é (confira abaixo a seção sobre melhores práticas de tráfego)

    Conforme indicado anteriormente, o Microsoft Graph é APIs nascidas na nuvem que têm as melhorias e otimizações mais recentes. Em geral, o Microsoft Graph consome menos recurso que CSOM e REST para obter a mesma funcionalidade. Portanto, a adoção do Microsoft Graph pode melhorar o desempenho do aplicativo e reduzir a limitação.

    Se você encontrar uma limitação, aproveite o cabeçalho HTTP Retry-After para garantir um atraso mínimo até que a limitação seja removida. Os cabeçalhos HTTP RateLimit enviam sinais iniciais quando você está perto dos limites e pode reduzir proativamente as solicitações para evitar atingir a limitação.

    Cabeçalho retry-after

    Quando os aplicativos experimentarem limitação, o SharePoint Online retornará um cabeçalho HTTP Retry-After na solicitação indicando quanto tempo em segundos o aplicativo de chamada deve aguardar antes de tentar novamente ou fazer uma nova solicitação.

    Respeitar o cabeçalho HTTP Retry-After é a maneira mais rápida de lidar com a limitação porque o SharePoint Online determina dinamicamente o momento certo para tentar novamente.

    As solicitações limitadas contam para os limites de uso, portanto, a falha ao respeitar o Retry-After pode resultar em mais limitação. Em outras palavras, as repetições agressivas funcionam contra a chamada de aplicativos porque, embora as chamadas falhem, elas ainda contam para os limites de uso. Respeitar o cabeçalho HTTP Retry-After garantirá o menor atraso e reduzirá as cotas de desperdício em solicitações limitadas.

    Cabeçalhos RateLimit – versão prévia

    Além do cabeçalho Retry-After na resposta de solicitações limitadas, o SharePoint Online também retorna os cabeçalhos RateLimit IETF para limites selecionados em determinadas condições para ajudar os aplicativos a gerenciar a limitação de taxa. Recomendamos que os aplicativos aproveitem esses cabeçalhos para evitar a aceleração.

    • RateLimit-Limit contém o limite na janela de tempo atual.
    • RateLimit-Remaining indica a cota restante na janela atual.
    • RateLimit-Reset indica o número de segundos até que a cota seja preenchida.

    Observação

    Esses cabeçalhos estão atualmente em beta e sujeitos a alterações. No momento em que os cabeçalhos foram adotados, a especificação de IETF estava em rascunho. A implementação atual é baseada no rascunho-03 da especificação IETF. Há o potencial de alterações quando a especificação é final e nos adaptaremos a essas alterações no futuro.

    Os cabeçalhos RateLimit são retornados em uma base de melhores esforços, portanto, os aplicativos podem não receber os cabeçalhos em todas as condições. Além disso, há outros limites que não são apresentados nos RateLimit cabeçalhos, para que os aplicativos possam ser limitados mesmo antes de atingir o limite descrito nos cabeçalhos RateLimit. Abaixo está a lista de limites para os qual damos suporte aos cabeçalhos RateLimit. As políticas e os valores estão sujeitos a alterações:

    limite Condição valor de limite Descrição
    Unidade de recurso de 1 minuto do aplicativo Uso >= 80% do limite Unidade de recurso Quando um aplicativo consome 80% ou mais do limite de 1 minuto do aplicativo, o limite restante e a redefinição são retornados.

    Abaixo estão alguns exemplos para ajudá-lo a entender os cabeçalhos RateLimit:

    • Um aplicativo consumiu 90% de sua cota de unidade de recurso (1.080 de 1.200) e seu consumo está dentro de todos os limites que se aplicam a ele. A solicitação é bem-sucedida e os cabeçalhos RateLimit são retornados.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Um aplicativo consumiu 100% de sua cota de unidade de recurso, portanto, ele é limitado devido a essa política. A solicitação é limitada e os cabeçalhos RateLimit são retornados. O Retry-After corresponde a RateLimit-Reset.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Um aplicativo consumiu 90% de sua cota de unidade de recurso, mas seu consumo já atingiu outros limites que os cabeçalhos RateLimit não dão suporte. Nesse caso, a solicitação é limitada e os cabeçalhos RateLimit não são retornados para evitar confusão, embora a condição para retornar os cabeçalhos seja atendida.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Informações adicionais podem ser encontradas em Evitar limitação em seu aplicativo usando cabeçalhos RateLimit no SharePoint Online

    Como decorar o tráfego http?

    O tráfego bem decorado será priorizado em relação ao tráfego que não está decorado corretamente.

    Qual é a definição de tráfego não decorado?

    • O tráfego é não decorado se não houver cadeias de caracteres do AppID/AppTitle e do Agente do Usuário em chamadas da API REST para o SharePoint Online. A cadeia de caracteres do Agente do Usuário deve estar em um formato específico, conforme descrito abaixo.
    • Se você estiver desenvolvendo um aplicativo Web em execução no navegador, a maioria dos navegadores modernos não permitirá a substituição da cadeia de caracteres do Agente do Usuário e você não precisará implementá-la.

    Quais são as recomendações?

    • Se você criou um aplicativo, a recomendação é registrar e usar AppID e AppTitle - isso garantirá a melhor experiência geral e o melhor caminho para qualquer resolução de problema futuro. Inclua também as informações da cadeia de caracteres do Agente do Usuário, conforme definido na etapa a seguir.

      Observação

      Consulte a documentação de identidade da Microsoft , como a página Início rápido: registrar um aplicativo na plataforma de identidade da Microsoft, para obter informações sobre como criar um aplicativo do Azure Active Directory.

    • Certifique-se de incluir a cadeia de caracteres do Agente do Usuário na sua chamada da API para o SharePoint com a seguinte convenção de nomenclatura

    Tipo Agente do Usuário Descrição
    Aplicativo ISV ISV|CompanyName|AppName/Version Identifique como ISV e inclua o Nome da Empresa, Nome do Aplicativo separado por um caractere de pipe e, em seguida, adicione o Número da Versão separado por um caractere de barra
    Aplicativo empresarial NONISV|CompanyName|AppName/Version Identifique como NONISV e inclua o Nome da Empresa, Nome do Aplicativo separado por um caractere de pipe e, em seguida, adicione o Número da Versão separado por um caractere de barra
    • Se você estiver criando suas próprias bibliotecas JavaScript, que são usadas para chamar APIs do SharePoint Online, certifique-se de incluir as informações do Agente do Usuário em sua solicitação http e possivelmente registrar seu aplicativo Web também como um Aplicativo, onde for adequado.

    Observação

    Espera-se que o formato da cadeia de caracteres do agente de usuário siga RFC2616, portanto, siga as diretrizes acima sobre os separadores certos. Também é bom anexar uma cadeia de caracteres do Agente do Usuário existente com as informações solicitadas.

    Cenários comuns de limitação no SharePoint Online

    As causas mais comuns de limitação no SharePoint Online por usuário são o modelo de objeto do cliente (CSOM) ou código de transferência de estado representacional (REST) que realiza ações muitos muito freqüentemente.

    • Tráfego esporádico

      A carga constante ou as consultas complexas repetitivas no SharePoint Online devem ser otimizadas para gerar um impacto reduzido. Caso as práticas recomendadas para a verificação de aplicativos que processam arquivos em massa não sejam seguidas, provavelmente levará à limitação. Esses aplicativos incluem mecanismos de sincronização, provedores de backup, indexadores de pesquisa, mecanismos de classificação, ferramentas de prevenção contra perda de dados e qualquer outra ferramenta que tente avaliar a totalidade dos dados e aplicar alterações a ele.

    • Tráfego cansativo

      Um único processo drasticamente excede os limites de limitação, continuamente, por um período de tempo.

      • Você usou o serviços web para criar uma ferramenta para sincronizar as propriedades de perfil de usuário. A ferramenta atualiza propriedades de perfil de usuário com base nas informações do seu sistema de recursos humanos (RH) linha de negócios (LOB). A ferramenta faz chamadas com uma freqüência muito alta.
      • Você está executando um script de teste de carga no SharePoint Online e acaba sendo limitado. O teste de carga não é permitido no SharePoint Online.
      • Você personalizou seu site de equipe em SharePoint Online, por exemplo, adicionando um indicador de status na Home page. Esse indicador de status atualiza com freqüência, que faz com que a página para fazer muitas chamadas para o serviço de SharePoint Online - isso disparado limitação.
      • Executar o cliente de sincronização do OneDrive enquanto também executa aplicativos de migração ou aplicativos que rastreiam sites e gravam dados podem resultar em grandes volumes de solicitação que podem desencadear limitações.

    • Casos de uso sem suporte

      O uso sem suporte do Microsoft Office SharePoint Online pode sofrer limitação. Usar o Microsoft Office SharePoint Online e o Microsoft OneDrive como um serviço intermediário entre o Microsoft 365 e outro repositório é um exemplo de caso de uso sem suporte.

    • Criar vários AppIDs para o mesmo aplicativo

      Não crie AppIDs separados em que os aplicativos executem essencialmente as mesmas operações, como backup ou prevenção contra perda de dados. Aplicativos em execução no mesmo locatário compartilham o mesmo recurso do locatário. Historicamente, alguns aplicativos têm tentado essa abordagem para contornar a limitação do aplicativo, mas acabaram esgotando o recurso do locatário e fazendo com que vários aplicativos fossem limitados no locatário.

    Limites específicos do cenário

    Ao usar autenticação somente de aplicativo com permissão Sites.Read.All

    Quando você estiver usando APIs de pesquisa do SharePoint Online com autenticação somente aplicativo e o aplicativo com permissão Sites.Read.All (ou mais forte), o aplicativo será registrado com permissões completas e poderá consultar todo o conteúdo do SharePoint Online (incluindo o conteúdo de OneDrive for Business privado do usuário).

    Para garantir que o serviço permaneça rápido e confiável, as consultas que usam essa permissão são limitadas em 25 solicitações por segundo. A consulta de pesquisa retornará com uma resposta http 429. Ao aguardar a recuperação de limitação, você deve pausar todas as solicitações de consulta de pesquisa que você pode estar fazendo no serviço usando uma permissão semelhante somente de aplicativo. Fazer chamadas adicionais enquanto recebe respostas de aceleração estenderá o tempo que leva para que seu aplicativo fique desenfreado.

    Ao pesquisar resultados de pesquisa de pessoas

    Ao pesquisar usando uma fonte de resultado que solicita resultados de pessoas, podemos limitar quaisquer solicitações que excedam um limite de 25 solicitações por segundo em toda a organização. Esse limite se aplica a todas as solicitações CSOM e REST de pesquisa do SharePoint usando a fonte de resultado "Resultados de Pessoas Locais" ou uma fonte de resultado de pesquisa de pessoas personalizadas.

    Se você tiver aplicativos ou componentes que estão fazendo com que suas solicitações de pesquisa de pessoas sejam limitadas, recomendamos que você:

    1. Considere se as solicitações são realmente necessárias para sua aplicação. Por exemplo, se você estiver usando um site de pesquisa personalizado, que faz muitas consultas simultâneas, verifique se algumas dessas solicitações podem ser removidas sem nenhum impacto significativo na experiência de pesquisa da sua organização. Como alternativa, considere experimentar nossa experiência moderna de pesquisa de pessoas no Microsoft Search pesquisando na página inicial do SharePoint. A pesquisa de pessoas no Microsoft Search foi otimizada para melhorar o desempenho e resultados mais relevantes.
    2. Evite fazer solicitações simultâneas. Por exemplo, em vez de emitir 10 solicitações de uma só vez, emita-as consecutivamente - apenas emita a próxima consulta após a conclusão da anterior. Pode ser necessário considerar o armazenamento em cache desses resultados se precisar deles rapidamente, por exemplo, em um carregamento de página.
    3. Tente consolidar as solicitações em uma única consulta. Por exemplo, em vez de fazer 10 consultas simultâneas para WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.com, tente a única consulta, WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Considere usar a API do Microsoft Graph se um cenário de alto volume de solicitações (acima de 25 solicitações por segundo) for realmente necessário.

    O que você deve fazer caso seja bloqueado no SharePoint Online?

    O bloqueio é a forma mais extrema de limitação. Raramente bloqueamos um locatário, a menos que detectemos um tráfego excessivo a longo prazo que possa ameaçar a integridade geral do serviço do SharePoint Online. Aplicamos bloqueios para impedir que esse tráfego excessivo prejudique o desempenho e a confiabilidade do SharePoint Online. Um bloqueio, que é colocado no nível do aplicativo ou do usuário, impede que um processo incorreto seja executado até que o problema seja corrigido. Se sua assinatura for bloqueada, você deverá adotar medidas para modificar os processos incorretos para que o bloqueio possa ser removido.

    Se bloquearmos sua assinatura, notificaremos você sobre o bloco no Centro de mensagens do Office 365. A mensagem descreve o que causou o bloqueio, fornece orientação sobre como resolver o problema e informa quem contatar para remover o bloqueio.

    Confira também