Evitar ficar limitado ou bloqueado no SharePoint Online

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

• O que é limitação?
• Como lidar com a limitação?
• Cenários comuns de limitação no SharePoint Online
• Limites específicos do cenário
• O que você deve fazer se obter bloqueado no SharePoint Online ?
• Recursos adicionais

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?

O SharePoint Online utiliza a limitação para manter o desempenho e a fiabilidade ideais do serviço SharePoint Online. A limitação limita o número de chamadas ou operações de API dentro de um período de tempo para impedir a utilização excessiva 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 pedidos que uma aplicação efetua, incluindo o Microsoft Graph, CSOM ou chamadas REST, o SharePoint Online devolve o código de estado HTTP 429 ("Demasiados pedidos") ou 503 ("Servidor Demasiado Ocupado") e os pedidos 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 é o serviço estar a registar 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 efetuadas coletivamente por aplicações em nome de um utilizador para impedir a utilização excessiva 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 pedido que uma aplicação faz em todos os pontos finais da API, incluindo o Microsoft Graph, CSOM e REST, conta para a utilização da aplicação.

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:

Para aplicações multi-inquilino:

1. Cada inquilino que aloja a aplicação é considerado distinto e funciona independentemente de outros. Consequentemente, cada aplicação está sujeita aos seus próprios limites de utilização em cada inquilino, conforme definido acima.
2. O consumo de unidades de recursos pela aplicação deve ser medido por inquilino e por aplicação. Isto garante que cada par inquilino-aplicação permanece dentro dos limites de recursos permitidos especificados para esse inquilino específico.
3. Se a aplicação atingir o limite de recursos dentro de um inquilino, esta ocorrência não afetará outras instâncias da aplicação que opera em inquilinos diferentes. A utilização de recursos de cada inquilino é isolada, o que impede o impacto entre inquilinos.

Em termos de custos de API, as APIs do Microsoft Graph têm um custo de unidade de recurso pré-determinada por pedido:

O Delta com um token é a forma mais eficiente de analisar conteúdos no SharePoint e falamos mais detalhadamente sobre as melhores práticas para analisar aplicações. 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 pré-determinada e normalmente consomem mais unidades de recursos do que as APIs do Microsoft Graph para obter a mesma funcionalidade. Além dos limites de unidades de recursos, a CSOM e a REST também estão sujeitas a outros limites de recursos internos, pelo que, se as aplicações chamarem CSOM e REST, poderão sofrer mais limitações do que os limites descritos neste documento. Recomendamos vivamente que escolha as APIs do Microsoft Graph em vez das APIs REST e CSOM sempre que possível.

Uma vez que os limites da aplicação estão em unidades de recursos, a taxa de pedido real, como pedidos por minuto, depende da escolha da API da aplicação e do custo da unidade de recurso da 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 aplicação tenha os seus limites num inquilino e permitamos que os inquilinos executem mais do que uma aplicação, várias aplicações em execução no mesmo inquilino partilham o mesmo registo de recursos e, em ocorrências raras, podem causar limitação de taxa quando muitas aplicações enviam pedidos 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 as APIs do Microsoft Graph em vez das APIs REST e CSOM sempre que 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 são APIs nascidas na cloud que têm as mais recentes melhorias e otimizações. Em geral, o Microsoft Graph consome menos recursos do que o CSOM e o REST para obter a mesma funcionalidade. Assim, a adoção do Microsoft Graph pode melhorar o desempenho da aplicação 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. Por outras palavras, as repetições agressivas funcionam contra a chamada de aplicações porque, apesar de as chamadas falharem, continuam a contar para os limites de utilização. 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

Para além do Retry-After cabeçalho na resposta a pedidos limitados, o SharePoint Online também devolve os cabeçalhos IETF RateLimit para limites selecionados em determinadas condições para ajudar as aplicações a gerir 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.

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:

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

Pode encontrar informações adicionais em Impedir a limitação na sua aplicação com 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 User-Agent deve estar num 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 de cadeia de carateres do Agente de Utilizador, conforme definido no passo seguinte.

  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 que inclui a cadeia de User-Agent na sua chamada à API para o SharePoint com a seguinte convenção de nomenclatura

• Se estiver a criar as suas próprias bibliotecas JavaScript, que são utilizadas para chamar APIs do SharePoint Online, certifique-se de que inclui as informações de User-Agent ao seu pedido HTTP e, potencialmente, registe a sua aplicação Web também como uma Aplicação, sempre que adequado.

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. Estas aplicações incluem motores de sincronização, fornecedores de cópias de segurança, indexadores de pesquisa, motores de classificação, ferramentas de prevenção de perda de dados e qualquer outra ferramenta, que tenta determinar a totalidade dos dados e aplicar alterações aos mesmos.

• Tráfego cansativo

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

  • 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. As aplicações em execução no mesmo inquilino acabam por partilhar o mesmo recurso que o inquilino. 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 estiver a utilizar APIs de pesquisa do SharePoint Online com autenticação apenas de aplicações e a aplicação com a permissão Sites.Read.All (ou mais forte), a aplicação será registada com todas as permissões e poderá consultar todos os seus conteúdos do SharePoint Online (incluindo o conteúdo privado do OneDrive para Empresas do utilizador).

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 devolverá 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 com permissões de utilizador delegados

A pesquisa com permissões de utilizador delegados ocorre quando uma aplicação submete um pedido de consulta de pesquisa com as permissões do utilizador com sessão iniciada. Os exemplos de pedidos delegados são os seguintes: a caixa de pesquisa numa página do SharePoint, uma peça Web baseada em pesquisa ou uma aplicação personalizada incorporada numa página do SharePoint e uma consulta de fluxo de trabalho do Power Automate para obter informações sobre o item.

Para garantir a estabilidade do serviço, o serviço limitará os pedidos de utilizador delegados que excedam os 10 pedidos por segundo por utilizador. Este limite por utilizador é agregado em todos os pedidos de todas as aplicações. Se um único utilizador enviar mais de 10 pedidos de consulta de pesquisa por segundo, é devolvido um HTTP 429. A aplicação requerente deve aguardar a duração do tempo limite especificado no cabeçalho de resposta antes de enviar os pedidos subsequentes. Ao conceber aplicações baseadas em pesquisa, páginas do SharePoint e fluxos de trabalho, os implementadores devem certificar-se de que a página e a aplicação não excedem os 10 pedidos por segundo no agregado e processam respostas de limitação 429. Para obter mais informações e documentação de orientação sobre a estruturação de páginas e a otimização da pesquisa, consulte Otimizar pedidos de pesquisa em páginas de sites modernas do SharePoint Online e Utilizar a ferramenta diagnóstico de páginas para o SharePoint Online.

Ao pesquisar resultados de pesquisa de pessoas

Ao pesquisar com uma origem de resultados que pede resultados às pessoas, podemos limitar todos os pedidos que excedam um limite de 25 pedidos por segundo em toda a organização. Este limite aplica-se a todos os pedidos CSOM e REST de pesquisa do SharePoint através da origem de resultados "Resultados de Pessoas Locais" ou de uma origem de resultados de pesquisa de pessoas personalizada.

Se tiver aplicações ou componentes, o que está a fazer com que os seus pedidos de pesquisa de pessoas sejam limitados, recomendamos que:

1. Considere se as solicitações são realmente necessárias para sua aplicação. Por exemplo, se estiver a utilizar um site de pesquisa personalizado, que faz muitas consultas simultâneas, verifique se alguns desses pedidos podem ser removidos sem qualquer 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 pedidos de uma só vez, emita-os consecutivamente - emita apenas a consulta seguinte 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, experimente 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.

Ao aceder a sites do OneDrive

Quando um cliente tenta aceder excessivamente a muitas coleções de sites do OneDrive que não existem, podemos limitar os pedidos do endereço IP desse cliente. O cliente receberá uma resposta HTTP 429 ao aceder a qualquer coleção de sites do OneDrive durante o período de limitação.

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

O bloqueio é a forma mais extrema de limitação. Raramente bloqueamos um inquilino, a menos que detetemos tráfego excessivo a longo prazo que possa ameaçar o estado de funcionamento geral do serviço 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

• Diagnóstico de problemas de desempenho no SharePoint Online
• Planejamento de capacidade e teste de carregamento do SharePoint Online
• Centro de desenvolvimento do Microsoft Graph
• Diretrizes de limitação do Microsoft Graph
• Impedir a limitação na sua aplicação com cabeçalhos RateLimit no SharePoint Online