Partilhar via

Estimar o desempenho e o planejamento de capacidade para fluxos de trabalho no SharePoint Server 2010

  • Artigo

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo sobre desempenho e planejamento de capacidade oferece orientação sobre o efeito que o uso do fluxo de trabalho causa em topologias executadas no Microsoft SharePoint Server 2010.

Para obter informações gerais sobre planejamento de capacidade para o SharePoint Server 2010, consulte Gerenciamento de desempenho e capacidade (SharePoint Server 2010).

Conteúdo

  • Características do farm de teste

  • Resultados do teste

  • Recomendações

  • Solução de problemas

Características do farm de teste

As seções a seguir descrevem as características do farm de teste:

  • Conjunto de dados

  • Carga de trabalho

  • Hardware, configurações e topologia

Conjunto de dados

Para obter níveis de referência, a maioria dos testes foi executada em um Site de Equipe padrão em um conjunto de sites único no farm. Os testes iniciais manuais iniciaram fluxos de trabalho usando uma lista com 8.000 itens.

Carga de trabalho

Os testes deste cenário ajudam a desenvolver estimativas de como configurações diferentes do farm respondem a alterações feitas nas seguintes variáveis:

  • Efeito do número de servidores front-end sobre a taxa de transferência para início manual de fluxos de trabalho declarativos em vários computadores

  • Efeito do número de servidores front-end sobre a taxa de transferência para início automático de fluxos de trabalho declarativos sobre a criação de itens em vários computadores

  • Efeito do número de servidores front-end sobre a taxa de transferência para a conclusão de tarefas em vários computadores

Os números específicos relativos à capacidade e ao desempenho apresentados neste artigo serão diferentes daqueles usados em ambientes reais. Os números aqui apresentados têm por objetivo fornecer um ponto de partida para o design de um ambiente dimensionado adequadamente. Depois de concluir o design inicial do sistema, teste a configuração para determinar se ela dará suporte aos fatores do seu ambiente.

Esta seção define os cenários de teste e aborda os processos de teste que foram usados para cada cenário. Informações detalhadas, como resultados de teste e parâmetros específicos, são fornecidas em cada seção de resultados de teste, mais adiante neste artigo.

Nome do teste Descrição do teste

Taxa de transferência para iniciar fluxos de trabalho manualmente

  1. Associa o fluxo de trabalho Aprovação de MOSS incluído em uma lista que cria uma tarefa.

  2. Preenche a lista com itens de lista.

  3. Chama o método de serviço Web StartWorkflow em Workflow.asmx em relação aos itens da lista por cinco minutos.

  4. Calcula a taxa de transferência examinando o número de fluxos de trabalho em andamento.

Taxa de transferência para iniciar fluxos de trabalho automaticamente quando um item é criado

  1. Associa o fluxo de trabalho de Aprovação do MOSS a uma lista que crie uma tarefa, definida para ser iniciada automaticamente quando um item for criado.

  2. Cria itens na lista por cinco minutos.

  3. Calcula a taxa de transferência examinando o número de fluxos de trabalho em andamento.

Taxa de transferência para a conclusão de tarefas de fluxo de trabalho

  1. Associa o fluxo de trabalho de Aprovação do MOSS a uma lista que crie uma tarefa, definida para ser iniciada automaticamente quando um item for criado.

  2. Cria itens na lista.

  3. Chama o método de serviço Web AlterToDo em Workflows.asmx em relação aos itens da tarefa que foi criada pelos fluxos de trabalho iniciados.

  4. Calcula a taxa de transferência examinando o número de fluxos de trabalho concluídos.

Hardware, configurações e topologia

As topologias que foram usadas para estes testes utilizam um único computador para o banco de dados de conteúdo e de um a quatro computadores front-end com a instalação padrão para o SharePoint Server 2010. Embora os fluxos de trabalho que foram usados nestes testes não estejam disponíveis no Microsoft SharePoint Foundation 2010, os resultados podem ser usados para estimar cenários semelhantes nestas implantações. O conjunto de dados que foi usado nestes testes contém um único conjunto de sites com um único site baseado no modelo Site de Equipe em um único banco de dados de conteúdo.

Para fornecer um alto nível de detalhes para o resultado do teste, várias configurações de farm foram usadas para teste. O intervalo de configurações de farm variou de um a quatro servidores Web e um único computador executando o Microsoft SQL Server 2008. Os testes foram executados em um computador cliente. O servidor de banco de dados e todos os servidores Web eram de 64 bits e o computador cliente era de 32 bits.

A tabela a seguir lista o hardware específico que foi usado para teste.

Servidor Web Servidor de banco de dados

Processador

2px4c@2.33GHz

4px4c@2.4GHz

RAM

4 GB

16 GB

Sistema operacional

Windows Server 2008 R2 x64

Windows Server 2008 R2 x64

Armazenamento

680 GB

4,2 terabytes

Quantidade de adaptadores de rede

2

2

Velocidade do adaptador de rede

1 gigabit

1 gigabit

Autenticação

NTLM

NTLM

Versão do software

4747

SQL Server 2008 R1

Número de instâncias do SQL Server

1

1

Tipo de balanceador de carga

Nenhum balanceador de carga

Nenhum balanceador de carga

Nível de log ULS

Média

Média

Topologia de planejamento de capacidade de fluxo de trabalho

Topologia de planejamento de fluxo de trabalho

Resultados do teste

As tabelas a seguir mostram os resultados do teste de fluxo de trabalho no SharePoint Server 2010. Para cada grupo de testes, somente determinadas variáveis específicas são alteradas para mostrar o efeito progressivo no desempenho de um farm.

Todos os testes relatados neste artigo foram conduzidos sem tempo de raciocínio, um atraso natural entre operações consecutivas. Em um ambiente do mundo real, cada operação é seguida por um atraso à medida que o usuário executa a próxima etapa da tarefa. Em contrapartida, no teste, cada operação foi imediatamente seguida pela próxima operação, o que resultou em uma carga contínua no farm. Essa carga pode causar retenção do banco de dados e outros fatores que podem afetar o desempenho adversamente.

O efeito da colocação do servidor Web em escala sobre a taxa de transferência

Os testes de taxa de transferência a seguir foram executados usando o fluxo de trabalho Aprovação, incluído no SharePoint Server 2010. A associação de fluxo de trabalho atribui uma tarefa e todas as instâncias são executadas em uma única lista. Cada instância desse fluxo de trabalho cria o seguinte banco de dados de conteúdo:

  • Uma entrada na tabela Fluxos de Trabalho para armazenar status de fluxo de trabalho

  • Cinco itens de lista secundários (uma tarefa e quatro itens de histórico)

  • Quatro receptores de evento para manipular eventos no item e na tarefa pais do fluxo de trabalho

O Limite de Adiamento de Fluxo de Trabalho foi definido como muito grande de forma que as operações do fluxo de trabalho nunca sejam enfileiradas. Cada teste foi executado cinco vezes e por cinco minutos.

Taxa de transferência de início manual

O teste na tabela a seguir mostra como a adição de servidores front-end afeta a taxa de transferência da adição de fluxos de trabalho de forma síncrona por meio do serviço Web. Esse teste foi executado com uma carga de usuário de 25 usuários simultâneos chamando continuamente o método StartWorkflow em Workflow.asmx e nenhuma outra carga no farm. A carga do usuário era a carga ideal antes da ocorrência de solicitações da Web descartadas. A lista foi previamente preenchida com até 8.000 itens.

Topologia RPS máximo de fluxo de trabalho de aprovação

1x1

14,35

2x1

24,08

3x1

29,7

4x1

30,77

O gráfico a seguir mostra como a taxa de transferência é alterada. A adição de servidores front-end não afeta necessariamente a taxa de transferência do farm de uma forma linear, mas gera picos em torno de três a quatro servidores front-end. Em resumo, a taxa de transferência máxima para fluxos de trabalho iniciados manualmente é de cerca de 30 fluxos de trabalho por segundo, e a adição de mais de quatro servidores front-end provavelmente terá um efeito insignificante.

Taxa de transferência de início manual

Taxa de transferência de início manual

Taxa de transferência de início automático de fluxos de trabalho quando itens são criados

O teste na tabela a seguir mostra como a adição de servidores front-end afeta a taxa de transferência do início automático de fluxos de trabalho quando itens são criados. Esse teste foi executado com uma carga de usuário de 150 usuários simultâneos chamando continuamente o serviço Web de lista para criar novos itens de lista e nenhuma outra operação no servidor. A lista foi iniciada como uma lista vazia.

Topologia RPS máximo de fluxo de trabalho de aprovação

1x1

13,0

2x1

25,11

3x1

32,11

4x1

32,18

O gráfico a seguir mostra como a taxa de transferência é alterada. A taxa de transferência é muito próxima das operações de início manual. De forma semelhante ao teste de início manual, a taxa de transferência tem picos de cerca de três ou quatro servidores front-end em aproximadamente 32 fluxos de trabalho por segundo. A adição de mais três ou quatro servidores front-end terá um efeito insignificante.

Taxa de transferência de fluxo de trabalho de inicialização automática

Taxa de transferência de fluxo de trabalho de inicialização automática

Taxa de transferência de conclusão de tarefa

O teste da tabela a seguir mostra como a adição de servidores front-end afeta a taxa de transferência de conclusão de tarefas de fluxo de trabalho. A lista de tarefas usada para iniciar fluxos de trabalho automaticamente no teste anterior foi a lista usada para concluir tarefas. Esse teste foi executado com uma carga de usuário de 25 usuários simultâneos chamando continuamente o método AlterToDo em Workflow.asmx e nenhuma outra operação no servidor. A lista começou como uma lista vazia.

Topologia RPS máximo de fluxo de trabalho de aprovação

1x1

13,5

2x1

23,86

3x1

27,06

4x1

27,14

O gráfico a seguir mostra como a taxa de transferência é alterada. De forma semelhante ao teste de início manual, a taxa de transferência tem picos de cerca de três ou quatro servidores front-end em aproximadamente 32 fluxos de trabalho por segundo. A adição de mais três servidores front-end terá um efeito insignificante.

Taxa de transferência de conclusão de tarefa

Taxa de transferência de conclusão de tarefa

Efeito do tamanho da lista e do número de instâncias de fluxo de trabalho sobre a taxa de transferência

O teste na tabela a seguir mostra como a taxa de transferência muda à medida que o número de fluxos de trabalho aumenta. O preenchimento dos dados foi feito pela execução contínua do teste de início automático de fluxo de trabalho até que 1 milhão de itens fossem criados na lista, parando em pontos de verificação diferentes no teste para executar medidas de taxa de transferência, como fizemos com os testes de taxa de transferência principal. Os testes foram executados em uma topologia 4x1.

Para manter a confiabilidade durante o preenchimento dos dados, tivemos que manter o enfileiramento de fluxos de trabalho ligado para impedir o atingimento do número máximo de conexões ao servidor de banco de dados. Se nenhuma conexão estiver disponível e se uma operação de fluxo de trabalho não puder se conectar ao banco de dados de conteúdo, a operação não poderá ser executada. Consulte Recomendações para obter mais informações sobre o enfileiramento de fluxos de trabalho.

Número de itens ou fluxos de trabalho Máximo de soluções de linha de base (RPS)

0

32,18

10

32

1.000

28,67

10.000

27,16

100.000

16,98

1.000.000

9,27

A taxa de transferência de início automático aumenta conforme o número de itens e os fluxos de trabalho

Taxa de transferência conforme o número de itens e os fluxos de trabalho aumentam

Para obter uma única lista e uma única tarefa e lista de histórico, a taxa de transferência diminui constantemente entre 1.000 e 100.000 itens. Entretanto, a taxa de degradação é reduzida depois desse ponto. Atribuímos a degradação da taxa de transferência a vários fatores.

Um fator é o número de linhas adicionadas a várias tabelas no banco de dados de conteúdo por instância. Como mencionado anteriormente, os fluxos de trabalho criam vários itens de lista além dos receptores de evento que cada instância de fluxo de trabalho registra. À medida que a tabela cresce em escopos diferentes, a adição de linhas fica mais lenta e o retardamento agregado para essas adições se torna uma degradação mais significativa do que a experimentada com a criação de apenas um item de lista.

O tamanho da lista de tarefas contribui para a sobrecarga adicional. Ao comparar a taxa de transferência para fluxos de trabalho executados em listas novas versus as novas listas de tarefas, as listas de tarefas têm um efeito maior sobre o desempenho. Isso acontece porque as listas de tarefas são registradas para receptores de evento do que os itens de lista pai. O gráfico a seguir descreve as diferenças.

Taxa de transferência com configurações de lista diferentes (fluxos de trabalho iniciados por segundo) Lista de tarefas de milhão de itens Lista de tarefas vazia

Lista de milhão de itens

9,27

12

Lista de itens vazia

9,3

13

Se você souber que terá de executar vários fluxos de trabalho em listas grandes e precisar de mais taxa de transferência do que seus testes mostram que você pode obter, verifique se as suas listas de tarefas podem ser separadas entre associações de fluxo de trabalho.

Recomendações

Esta seção oferece recomendações gerais sobre desempenho e capacidade. Use essas recomendações para determinar as características de capacidade e desempenho da topologia inicial que você criou para decidir se terá de expandir ou ampliar a topologia inicial.

Para obter informações específicas sobre requisitos mínimos ou recomendados do sistema, consulte Requisitos de hardware e software (SharePoint Server 2010).

Topologias expandidas

Você pode aumentar a taxa de transferência do fluxo de trabalho expandindo até quatro servidores Web. Além disso, o aumento será insignificante. A taxa de transferência de fluxo de trabalho pode ser restrita por configurações de fluxo de trabalho relacionadas a desempenho. Essas configurações são descritas em mais detalhes em Enfileiramento de fluxo de trabalho e configurações relacionadas a desempenho.

Estimando destinos de taxa de transferência

Vários fatores podem afetar a taxa de transferência. Entre eles, o número de usuários e o tipo, a complexidade e a frequência de operações de usuário. Fluxos de trabalho mais complexos que executam várias operações no banco de dados de conteúdo ou se registram para mais eventos serão executados com mais lentidão e consumirão mais recursos do que outros fluxos de trabalho.

O fluxo de trabalho usado neste teste cria várias entradas no banco de dados de conteúdo que serão inseridas nas atividades da tarefa. Se você espera ter fluxos de trabalho com um número pequeno de tarefas, poderá esperar características de taxa de transferência similares. Se a maioria dos fluxos de trabalho contiver operações muito leves, a taxa de transferência poderá ser aumentada. Se os seus fluxos de trabalho consistirem em várias tarefas, ou em operações de back-end intensas ou em poder de processamento, você poderá esperar uma redução na taxa de transferência.

Além de compreender o que os fluxos de trabalho farão, considere onde eles serão executados e se eles serão executados em listas grandes, nas quais a taxa de transferência será reduzida com o tempo.

O SharePoint Server 2010 pode ser implantado e configurado de várias maneiras. Como resultado, não há uma maneira fácil de estimar quantos usuários poderão ter suporte de um determinado número de servidores. Dessa forma, conduza testes em seu próprio ambiente antes de implantar o SharePoint Server 2010 em um ambiente de produção.

O enfileiramento de fluxo de trabalho e as configurações relacionadas a desempenho

O fluxo de trabalho usa um sistema de enfileiramento para controlar o estresse relacionado a fluxo de trabalho em recursos de farm e no banco de dados de conteúdo. Usando esse sistema, quando o número de fluxos de trabalho em execução em um banco de dados atinge um limite configurado pelo administrador, sucessivas operações de fluxo de trabalho são adicionadas à fila a ser executada pelo serviço do timer de Fluxo de Trabalho. Por padrão, esse serviço recebe um lote de itens de trabalho de fluxo de trabalho por meio de trabalhos de timer a cada minuto.

Várias configurações de administrador do farm direta e indiretamente relacionadas ao mecanismo de enfileiramento afetam o desempenho e o dimensionamento do fluxo de trabalho. As seções a seguir descrevem o que essas configurações fazem e como ajustá-las para atender a requisitos de desempenho.

Compreendendo as configurações básicas de fila

Os administradores do farm podem ajustar as configurações a seguir para configurar características básicas do sistema de enfileiramento:

  • Limite de Adiamento de Fluxo de Trabalho (Set-SPFarmConfig –WorkflowPostponeThreshold <inteiro>)

    O número máximo de fluxos de trabalho que podem ser executados em um único banco de dados de conteúdo antes que solicitações e operações adicionais sejam enfileiradas. Os fluxos de trabalho enfileirados mostram um status Iniciando. Essa é uma configuração geral do site com o valor padrão 15. Isso representa o número de operações de fluxo de trabalho em processamento em um momento e não o número máximo de fluxos de trabalho que podem estar em andamento. Quando as operações de fluxo de trabalho forem concluídas, sucessivas operações poderão ser executadas.

  • Tamanho do Lote de Entrega de Evento de Fluxo de Trabalho (Set-SPWorkflow –BatchSize <inteiro>)

    O serviço Timer do Fluxo de Trabalho é uma exceção ao limite de adiamento e recupera lotes de itens da fila e os executa um por vez. Esses lotes podem ser maiores do que o limite de adiamento. O número de itens de trabalho que o serviço recebe por execução é definido usando a propriedade BatchSize. A propriedade BatchSize pode ser definida uma vez por instância de serviço. O valor padrão é 100. Durante a execução em servidores de aplicativos que não estejam configurados como servidores front-end, o serviço Timer do Fluxo de Trabalho exige que sejam definidas configurações de fluxo de trabalho do arquivo Web.config no banco de dados de configuração. Isso deve ser feito por meio de um script que chama UpdateWorkflowConfigurationSettings() no objeto SPWebApplication, que copiará as configurações de Web.config de um servidor front-end.

  • Frequência do Trabalho Timer do Fluxo de Trabalho (Set-SPTimerJob job-workflow –schedule <cadeia de caracteres>)

    A frequência na qual o serviço Timer do Fluxo de Trabalho é executado pode ser ajustada por meio de configurações de trabalho de timer. Por padrão, o serviço é definido para ser executado a cada cinco minutos. Isso significa que pode haver um atraso de cinco minutos antes que os itens de trabalho na parte superior da fila sejam processados.

    Observação

    Itens de trabalho agendados, como expirações de data de vencimento de tarefa, também são separados pelo mesmo mecanismo de timer. Dessa forma, serão atrasados pelo menos intervalo de tempo.

O serviço Timer do Fluxo de Trabalho pode ser desligado em cada servidor usando a Administração de Serviços Compartilhados na Administração Central. Por padrão, ele será executado em todos os servidores front-end do farm. Cada trabalho será iterado em todos os aplicativos Web e bancos de dados de conteúdo no farm.

A combinação de limite de adiamento, tamanho do lote e frequência do timer pode ser usada para limitar operações de fluxo de trabalho no banco de dados. A taxa de transferência máxima será afetada pela velocidade em que as operações são enfileiradas e processadas a partir da fila.

Por exemplo, com as configurações padrão, um único serviço de timer e um único banco de dados de conteúdo, se houver 1.000 itens na fila, serão necessárias dez execuções do trabalho de timer para executá-los todos, o que levará 50 minutos. Entretanto, se você definir o tamanho do lote como 1.000 e definir o trabalho de timer para ser executado a cada minuto, as operações começarão a ser executadas após um minuto. Se você definir o limite de adiamento como maior, mais operações serão executadas simultaneamente, reduzindo o número de solicitações enfileiradas e reduzindo o tempo total necessário para o processamento desses fluxos de trabalho.

Observação

Recomendamos a configuração do limite de adiamento para no máximo 200, uma vez que instâncias de fluxo de trabalho simultâneas são executadas em seus próprios threads e cada uma abrirá novas conexões do SQL Server, potencialmente atingindo os limites máximos de conexão no servidor de banco de dados com o tempo.

Se você não quiser que os fluxos de trabalho sejam executados em servidores front-end e se souber que as operações não precisam ocorrer imediatamente, poderá isolar o serviço Timer do Fluxo de Trabalho para ser executado em servidores de aplicativos selecionados, definir o limite de adiamento como um número muito baixo para impor que os fluxos de trabalho normalmente sejam executados no serviço de timer e definir o tamanho do lote com o tamanho suficiente para receber itens com mais rapidez e frequência. Se quiser garantir que os fluxos de trabalho sejam executadas de maneira mais síncrona no sistema, defina o limite de adiamento como maior de forma que os fluxos de trabalho não sejam adiados com frequência e que tenham um efeito mais imediato.

Modifique essas configurações para otimizar a forma como deseja que os fluxos de trabalho operem. Recomendamos experimentar configurações diferentes e testá-las para otimizá-las para seus ambientes e requisitos.

Ajustando configurações para o enfileiramento

Se o farm for manter uma carga pesada de fluxo de trabalho por longos períodos ou se houver vários eventos de atraso enfileirados a partir de fluxos de trabalho no sistema, o número de operações de fluxo de trabalho enfileiradas aumentará. Além das configurações básicas de fila, talvez seja necessário ajustar as configurações a seguir para manter a fila em bom estado de integridade:

  • Tamanho do Lote de Entrega de Evento de Item de Trabalho

    A tabela usada pelo fluxo de trabalho para eventos enfileirados é uma tabela de itens de trabalho geral compartilhada com outros recursos que não são fluxos de trabalho no SharePoint Server 2010. Dessa forma, há outro trabalho de timer que retira da fila os itens de trabalho que não sejam fluxo de trabalho. Semelhante ao tamanho de lote de evento de fluxo de trabalho, o tamanho de lote de entrega de evento de item de trabalho especifica o número de itens de trabalho que não sejam fluxo de trabalho que são retirados da fila em um momento.

  • Frequência de Trabalho de Timer de Failover de Fluxo de Trabalho

    Em raras circunstâncias, se os eventos de fluxo de trabalho não puderem ser entregues a uma instância de fluxo de trabalho, a entrega de evento será agendada na fila como um item de trabalho de failover a ser tentado novamente mais tarde (começando com 5 minutos depois, 10 minutos se falhar novamente, 20 minutos e assim por diante). Um trabalho de timer de failover de fluxo de trabalho retira da fila itens de trabalho de failover e essa configuração ajusta a frequência na qual o timer de failover será executado. Por padrão, ele é executado a cada 15 minutos.

  • Tamanho de Lote de Failover de Fluxo de Trabalho

    De forma similar às configurações de fluxo de trabalho e de tamanho de lote de item de trabalho, essa configuração controla o número de eventos de failover que cada trabalho de timer de failover irá retirar da fila.

    Como há vários trabalhos de timer que operam na mesma tabela, muitos dos itens enfileirados poderão causar a retenção do banco de dados e reduzir a taxa de transferência e a confiabilidade. Para reduzir a retenção, recomendamos o seguinte:

    • Equilibre o Limite de Adiamento e o Tamanho de Lote de Fluxo de Trabalho de forma que o tamanho do lote seja pequeno o suficiente ou que a frequência do trabalho de timer seja alta o suficiente para que o trabalho de timer possa ser concluído antes que o próximo trabalho de timer inicie para impedir a criação de execuções de trabalho de timer em paralelo em excesso e que não possam ser concluídas.

    • Para evitar bloqueios de tabela, não defina nenhuma das duas configurações de tamanho de lote como mais de 5.000.

Dica

Desloque a frequência dos trabalhos de timer de fluxo de trabalho, de item de trabalho e de failover de forma que eles nem sempre sejam executados nos mesmos momentos. Para obter uma lista extensa com fluxos de trabalho, quatro minutos para o trabalho de timer do fluxo de trabalho e seis minutos para o failover funcionaram bem em nossos scripts de preenchimento de dados.

Aprimorando o dimensionamento para listas de tarefas e de histórico

Os fluxos de trabalho geram várias tarefas e itens de histórico por instância. Por padrão, essas listas são indexadas para ajudar no dimensionamento, mas à medida que elas aumentam, o desempenho sempre irá diminuir. Para reduzir a taxa de diminuição, mantenha listas de histórico e de tarefas separadas para associações de fluxo de trabalho diferentes e altere periodicamente essas listas nas configurações de associação de fluxo de trabalho quando essas listas ficarem grandes.

O fluxo de trabalho também tem um trabalho de timer diário (job-workflow-autoclean) que excluirá automaticamente instâncias e tarefas de fluxo de trabalho para instâncias que foram concluídas há mais de 60 dias. Deixe esse trabalho de timer ligado para manter as listas de tarefas e eventos limpas, o máximo possível. Se os dados tiverem de ser preservados, grave-os em outras listas ou em locais de arquivamento. Os itens de histórico de fluxo de trabalho não são excluídos por esse trabalho de timer. Se for preciso limpá-los, isso deverá ser feito com um script ou manualmente por meio da interface do usuário de lista.

Outras considerações

A remoção de colunas das listas faz com que uma operação de banco de dados seja proporcional ao número de itens da lista. A remoção de associações de fluxo de trabalho removerá a coluna de status do fluxo de trabalho da lista. Isso causará uma grande operação em listas grandes. Se você souber que uma lista tem milhões de itens, defina o fluxo de trabalho como Nenhuma Instância Nova em vez de remover os fluxos de trabalho.

Solução de Problemas

Gargalo Causa Solução

Contenção de banco de dados (bloqueios)

Os bloqueios de banco de dados impedem que vários usuários façam modificações conflitantes em um conjunto de dados. Quando um conjunto de dados é bloqueado por um usuário ou processo, nenhum outro usuário pode alterar o mesmo conjunto de dados até que o primeiro usuário ou processo esteja concluído, alterando os dados e liberando o bloqueio.

Para ajudar a reduzir a incidência de bloqueios de banco de dados, você pode fazer o seguinte:

  • Distribuir fluxos de trabalho entre mais bibliotecas de documentos.

  • Ampliar o servidor de banco de dados.

  • Ajustar o disco rígido do servidor de banco de dados para escrita/gravação.

Existem métodos para contornar o sistema de bloqueio do banco de dados no SQL Server 2005, como o parâmetro NOLOCK. Entretanto, não recomendamos ou oferecemos suporte ao uso desse método por causa da possibilidade de corrupção de dados.

E/S de disco do servidor de banco de dados

Quando o número de solicitações de E/S para um disco rígido excede a capacidade de E/S do disco, as solicitações são enfileiradas. Como resultado, o tempo para a conclusão de cada solicitação aumenta.

A distribuição de arquivos de dados entre várias unidades físicas permite a E/S em paralelo. O blog sobre alocação de disco e E/S de disco do SharePoint (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x416) contém informações úteis sobre a resolução de problemas de E/S de disco.

Utilização da CPU do servidor Web

Quando um servidor Web é sobrecarregado com solicitações de usuário, a utilização média da CPU ficará próxima aos 100%. Isso impede que o servidor Web responda a solicitações e pode causar o atingimento de tempos limites ou mensagens de erro em computadores clientes.

Esse problema pode ser resolvido de duas maneiras. Você pode adicionar servidores Web ao farm para distribuir a carga de usuário ou pode estender o servidor ou servidores Web adicionando processadores mais rápidos.

Servidores Web

A tabela a seguir mostra contadores de desempenho e processos para o monitoramento de servidores Web em um farm.

Contador de desempenho Aplicar a objeto Observações

Tempo de processador

Total

Mostra o percentual do tempo decorrido em que este thread usou o processador para executar instruções.

Utilização de memória

Pool de aplicativos

Mostra a utilização média de memória do sistema para o pool de aplicativos. Você deve determinar o pool de aplicativos correto a ser monitorado.

A diretriz básica é determinar a utilização de pico de memória para um determinado aplicativo Web e atribuir esse número mais 10 ao pool de aplicativos associado.

Servidores de banco de dados

A tabela a seguir mostra contadores de desempenho e processos para o monitoramento de servidores de banco de dados em seu farm.

Contador de desempenho Aplicar a objeto Observações

Comprimento médio da fila de discos

Disco rígido que contém SharedServices.mdf

Valores médios maiores do que 1,5 por fuso indicam que os tempos de gravação para aquele disco rígido são insuficientes.

Tempo de processador

Processo do SQL Server

Valores médios maiores do que 80% indicam que a capacidade do processador no servidor de banco de dados é insuficiente.

Tempo de processador

Total

Mostra o percentual do tempo decorrido em que este thread usou o processador para executar instruções.

Utilização de memória

Total

Mostra a utilização média da memória do sistema.

See Also

Other Resources

Artigo sobre escalabilidade e desempenho do fluxo de trabalho no Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x416)