SharePoint 2013 estrangulamento e desempenho no SharePoint e Project

Estrangulamento do serviço de fluxo de trabalho

O estrangulamento é realizado para permitir uma utilização justa dos recursos. Também protege o ambiente de fluxos de trabalho prejudiciais e fluxos de trabalho que não seguem as melhores práticas. O estrangulamento do serviço workflow não é controlado pela SharePoint. O serviço de fluxo de trabalho e o SharePoint são dois serviços independentes, e cada serviço acelera os pedidos no interesse da saúde geral do serviço. No serviço de fluxo de trabalho, o estrangulamento é realizado ao nível de âmbito de fluxo de trabalho que se alinha com os sites sharePoint. A aceleração não é globalmente contabilizada. Em vez disso, cada serviço de back-end de fluxo de trabalho rastreia o uso de um âmbito de fluxo de trabalho de forma independente. Pode haver um ou mais fluxos de trabalho num âmbito de fluxo de trabalho. O estrangulamento do fluxo de trabalho é dinâmico e será reavaliado periodicamente pelo âmbito do fluxo de trabalho e pelo back end do serviço de fluxo de trabalho. 

O serviço Workflow também limita o número de pedidos de saída que uma única instância de fluxo de trabalho pode gerar. Num período de 24 horas, uma única instância de fluxo de trabalho pode gerar até 5.000 pedidos de saída. Após 5.000 pedidos de saída gerados num período de 24 horas, o fluxo de trabalho é suspenso pelo serviço workflow.

A página de Estado do Fluxo de Trabalho para o fluxo de trabalho conterá informações sobre o fluxo de trabalho suspenso. Neste cenário, o balão de informação para o Estado Interno apresentará a seguinte mensagem:

• O caso excedeu a quota de pedido de saída para um período de tempo de 1.00:00:00. O limite de pedido de 5000 foi atingido em <tempo>.
  
  NOTA: O <tempo> espaço reservado representa o tempo que demorou a atingir o limite de 5.000 pedidos para o seu fluxo de trabalho.

Pode retomar a instância de fluxo de trabalho suspensa clicando em Currículo para o fluxo de trabalho ou utilizando o Modelo de Objeto de Cliente do Fluxo de Trabalho sharePoint após o passar de 24 horas. Isto deve ocorrer antes de o fluxo de trabalho ser interrompido.

Se o fluxo de trabalho exceder o limite de utilização do CPU, a página de Estado do Fluxo de Trabalho para o fluxo de trabalho conterá informações sobre o fluxo de trabalho suspenso. Neste cenário, o balão de informação para o Estado Interno apresentará a seguinte mensagem: 

• A instância de fluxo de trabalho excedeu o limite de utilização do CPU de aceleração de 00:00:01.2000000 e não pôde ser descarregada por não ser pernosa.

As instâncias de fluxo de trabalho suspensas serão encerradas após 10 dias. O balão de informação para o Estado Interno apresentará a seguinte mensagem se o fluxo de trabalho for encerrado:

• System.Activities.Statements.WorkflowTerminatedException: A ocorrência foi transferida do estado suspenso para o estado encerrado porque expirou.

Um fluxo de trabalho encerrado será eventualmente limpo. Depois de um fluxo de trabalho encerrado ser limpo, apresentará a seguinte mensagem:

• Desculpa, alguma coisa correu mal.
  Não conseguimos encontrar o fluxo de trabalho. As instâncias completas são automaticamente limpas

Âmbitos de fluxo de trabalho

Um âmbito de fluxo de trabalho é definido como um site numa coleção de site. Por exemplo, o seguinte URL destina-se a uma recolha de sites de raiz e é considerado um âmbito de fluxo de trabalho:

    https://contoso.sharepoint.com/sites/rootsite

Um exemplo de outro âmbito de fluxo de trabalho que está na mesma coleção do site é o seguinte. No entanto, este âmbito de fluxo de trabalho encontra-se num subsite.

    https://contoso.sharepoint.com/sites/rootsite/subsite

O que é um pedido?

Os fluxos de trabalho do SharePoint 2013 são construídos com base no modelo de add-ins para o SharePoint, e utilizam APIs DE REST para interagir com os dados do SharePoint. Para saber mais, vá ao Serviço Desempreso SharePoint 2013 REST.

Um pedido é uma chamada de rede do serviço de fluxo de trabalho para um ponto final do SharePoint ou do Project REST API. Não há diferença entre o tipo de pedido ou a resposta para um dado pedido. Uma ação e as suas atividades de composição não contribuem para a contagem de pedidos a menos que o pedido envolva uma API de REST SharePoint 2013. Por exemplo, a ação 'Registar para Lista de História' pode gerar cinco ou mais pedidos para uma operação saudável. Além disso, a lógica de relírra é incorporada em fluxos de trabalho no caso de algo correr mal. Isto pode gerar pedidos adicionais.

Muitas ações produzem pedidos, e os pedidos podem ser minimizados utilizando as melhores práticas. Por exemplo, pode utilizar uma única ação de Item de Lista de Atualização em vez de várias ações de set Field in Current Item para reduzir o número de pedidos que estão a ser feitos por um âmbito de fluxo de trabalho e ainda obter os mesmos resultados. 

Recomendações de design de fluxo de trabalho

Há muitas maneiras de gerar muitos pedidos num fluxo de trabalho que pode resultar em estrangulamento. Alguns exemplos gerais são os seguintes:

• Um fluxo de trabalho de ciclo agressivo ou múltiplos fluxos de trabalho agressivamente em loop

• Um fluxo de trabalho que está associado a uma lista ou biblioteca enquanto o conteúdo está a ser migrado para o SharePoint.

• Versões de fluxo de trabalho problemáticas anteriores que foram corrigidas e que continuam a executar casos de fluxo de trabalho que têm a configuração problemática até que o fluxo de trabalho seja terminado.

O estrangulamento do âmbito do fluxo de trabalho que é aplicado pelo serviço de fluxo de trabalho deve permitir cenários típicos de utilização do fluxo de trabalho. No entanto, à medida que a lógica de um fluxo de trabalho se torna mais sofisticada, o fluxo de trabalho pode exceder limites seguros.

Os seguintes cenários específicos de fluxo de trabalho resultarão também em estrangulamento.