Teste de desempenho para SharePoint Server 2013

APLICA-SE A:2013 2016 2019 Subscription Edition SharePoint no Microsoft 365

Este artigo descreve como testar o desempenho do SharePoint Server 2013. O estágio de teste e otimização é um componente fundamental do gerenciamento eficaz da capacidade. Deve testar novas arquiteturas antes de implementá-las na produção e deve realizar testes de aceitação com as seguintes melhores práticas de monitorização para garantir que as arquiteturas que concebe alcançam os objetivos de desempenho e capacidade. Isso permite identificar e otimizar gargalos em potencial antes de eles afetarem os usuários em uma implantação ativa. Se estiver a atualizar a partir de um ambiente do Office SharePoint Server 2007 e planear fazer alterações arquitetónicas ou estiver a estimar a carga de utilizador das novas funcionalidades do SharePoint Server 2013, teste importante para garantir que o seu novo ambiente baseado no SharePoint Server 2013 irá cumprir os objetivos de desempenho e capacidade.

Depois de testar o seu ambiente, pode analisar os resultados do teste para determinar que alterações têm de ser efetuadas para alcançar os objetivos de desempenho e capacidade que estabeleceu no Passo 1: Planeamento de capacidade do SharePoint Server 2013.

Estes são os subpassos recomendados que deve seguir para a pré-produção:

• Criar um ambiente de teste que imite a arquitetura inicial projetada na Etapa 2: design.

• Preencher o armazenamento com o conjunto de dados ou parte do conjunto de dados identificada na Etapa 1: modelo.

• Sobrecarregar o sistema com uma carga sintética que representa a carga de trabalho identificada na Etapa 1: modelo.

• Executar testes, analisar resultados e otimizar a arquitetura.

• Implantar a arquitetura otimizada no data center e fazer a distribuição de um piloto com um conjunto menor de usuários.

• Analisar os resultados do piloto, identificar gargalos em potencial e otimizar a arquitetura. Testar novamente, se necessário.

• Implantar no ambiente de produção.

Antes de ler este artigo, deve ler Capacity management and sizing overview for SharePoint Server 2013 (Descrição geral da gestão de capacidade e dimensionamento do SharePoint Server 2013).

Criar um plano de teste

Verifique se o seu plano inclui:

• Hardware projetado para operar nas metas de desempenho de produção esperadas. Sempre meça o desempenho dos sistemas de teste de maneira conservadora.

• Se tiver código personalizado ou componente personalizado, é importante que teste primeiro o desempenho desses componentes isoladamente para validar o respetivo desempenho e estabilidade. Depois de estarem estáveis, deve testar o sistema com esses componentes instalados e comparar o desempenho com o farm sem os mesmos instalados. Componentes personalizados frequentemente são um fator importante para problemas de desempenho e confiabilidade em sistemas de produção.

• Conheça o objetivo do seu teste. Entenda antecipadamente quais são os objetos do teste. Validar o desempenho de alguns novos componentes personalizados que foram desenvolvidos para o farm? Ver quanto tempo levará para rastrear e indexar um conjunto de conteúdos? Determinar quantas solicitações por segundo o farm pode suportar? Pode haver muitos objetivos diferentes durante um teste e a primeira etapa para desenvolver um bom plano de teste é decidir quais são os seus objetivos.

• Entenda como medir o objetivo do seu teste. Se estiver interessado em medir a capacidade de débito do farm, por exemplo, vai querer medir o RPS e a latência da página. Se estiver a medir o desempenho da pesquisa, deverá medir o tempo de pesquisa e as taxas de indexação de documentos. Se o seu objetivo de teste for bem compreendido, isso ajudará a definir que indicadores de desempenho principais você precisa validar para executar seus testes.

Criar o ambiente de teste

Assim que definir seus objetivos de teste e suas medições, e determinar quais são as exigências de capacidade para o seu farm (nas etapas 1 e 2 deste processo), o próximo objetivo é projetar e criar o ambiente de teste. O esforço para criar um ambiente de teste frequentemente é subestimado. Ele deve duplicar o ambiente de produção da maneira mais fiel possível. Alguns dos recursos e funcionalidades que você deve considerar ao projetar o ambiente de teste incluem:

• Autenticação: decida se o farm irá utilizar os Serviços de Domínio do Active Directory (AD DS), a autenticação baseada em formulários (e se sim, com que diretório), autenticação baseada em afirmações, etc. Independentemente do diretório que estiver a utilizar, quantos utilizadores precisa no seu ambiente de teste e como os vai criar? De quantos grupos ou funções você precisará e como irá criá-los e preenchê-los? Você também precisa garantir que tenha recursos suficientes alocados para seus serviços de autenticação para que não se tornem um gargalo durante o teste.

• DNS: saiba quais são os espaços de nomes de que irá precisar durante o teste. Identifique que servidores irão responder a esses pedidos e certifique-se de que incluiu um plano que tem os endereços IP que serão utilizados por que servidores e que entradas DNS terá de criar.

• Balanceamento de carga: partindo do princípio de que está a utilizar mais do que um servidor (que normalmente teria ou provavelmente não teria carga suficiente para justificar o teste de carga), precisará de algum tipo de solução de balanceador de carga. Essa pode ser um dispositivo de balanceamento de carga ou você pode usar um software de balanceamento de carga, como Windows NLB. Descubra o que irá utilizar e anote todas as informações de configuração necessárias para configurá-la de forma rápida e eficiente. Outra coisa a ter em atenção é que os agentes de teste de carga normalmente tentam resolver o endereço para um URL apenas uma vez a cada 30 minutos. Isto significa que não deve utilizar um ficheiro de anfitriões local ou um DNS round robin para balanceamento de carga, porque os agentes de teste provavelmente acabarão por ir para o mesmo servidor para cada pedido, em vez de equilibrar em torno de todos os servidores disponíveis.

• Servidores de teste: quando planeia o seu ambiente de teste, não só tem de planear os servidores para o farm do SharePoint Server 2013, como também tem de planear as máquinas necessárias para executar os testes. Normalmente, isso incluirá três servidores no mínimo; pode ser necessário mais. Se estiver a utilizar o Visual Studio Team System (Team Test Load Agent) para efetuar o teste, será utilizada uma máquina como controlador de teste de carga. Geralmente, existem dois ou mais computadores que são utilizados como agentes de teste de carga. Os agentes são os computadores que recebem as instruções do controlador de teste sobre o que testar e emitir os pedidos para o farm do SharePoint Server 2013. Os resultados do teste em si são armazenados em um computador baseado em SQL Server. Não deve utilizar o mesmo computador baseado no SQL Server que é utilizado para o farm do SharePoint Server 2016, porque escrever os dados de teste irá distorcer os recursos do SQL Server disponíveis para o farm do SharePoint Server 2013. Também tem de monitorizar os servidores de teste ao executar os testes, da mesma forma que monitorizaria os servidores no farm do SharePoint Server 2013 ou controladores de domínio, etc. para garantir que os resultados dos testes são representativos do farm que está a configurar. Às vezes, os agentes ou o controlador de carga podem eles próprios se tornar o gargalo. Se isso acontecer, o débito que vê no teste normalmente não é o máximo que o farm pode suportar.

• SQL Server: no seu ambiente de teste, siga as orientações nas secções "Configurar o SQL Server" e "Validar e monitorizar o armazenamento e o desempenho do SQL Server" no artigo Planeamento e configuração da capacidade do SQL Server e armazenamento (SharePoint Server).

• Validação de conjuntos de dados: à medida que decide em que conteúdo vai executar testes, lembre-se de que, na melhor das hipóteses, irá utilizar dados de um sistema de produção existente. Por exemplo, você pode fazer o backup dos bancos de dados de conteúdo de um farm de produção e restaurá-los para o ambiente de teste, e anexar os bancos de dados para colocar o conteúdo no farm. Sempre que você executa testes com relação a dados inventados ou de amostra, corre o risco de os resultados serem tendenciosos devido às diferenças no corpus do conteúdo.

Se você tem de criar dados de amostra, há algumas considerações a ter em mente na criação do conteúdo:

• Todas as páginas devem ser publicadas; nada deve passar por check-out

• A navegação deve ser realista; não crie além do que razoavelmente esperaria usar em produção.

• Você deve ter uma ideia das personalizações que o site de produção usará. Por exemplo, páginas mestre, folhas de estilo, JavaScript etc. devem todas ser implantadas em um ambiente de teste o mais fielmente possível ao ambiente de produção.

• Determine quantos grupos e/ou níveis de permissão do SharePoint vai precisar e como vai associar os utilizadores aos mesmos.

• Determine se precisará realizar importações de perfis e quanto tempo isso levará.

• Determine se precisará de públicos e como irá criá-los e preenchê-los.

• Determine se precisa de mais origens de conteúdo de pesquisa e o que terá de criar. Se não precisar criá-las, determine se terá acesso de rede para poder rastreá-las.

• Determine se tem dados de exemplo suficientes - documentos, listas, itens de lista, etc. Caso contrário, crie um plano para a forma como irá criar este conteúdo.

• Tenha um plano de conteúdo único suficiente para fazer uma pesquisa de teste de modo adequado. Um erro comum é carregar o mesmo documento - talvez centenas ou mesmo milhares de vezes - para diferentes bibliotecas de documentos com nomes diferentes. Isso pode afetar o desempenho de pesquisa porque o processador de pesquisa passará uma quantidade de tempo ordenada realizando detecção de duplicatas que de outra forma não precisará fazer em um ambiente de produção com conteúdo real.

Criar testes e ferramentas

Depois de o ambiente de teste estar funcional, está na altura de criar e ajustar os testes que serão utilizados para medir a capacidade de desempenho do farm. Esta seção, às vezes, fará referências especificamente para o Visual Studio Team System (Team Test Load Agent), mas muitos dos conceitos se aplicam independentemente de que ferramenta de teste de carga você usa. Para obter mais informações sobre as ferramentas de teste disponíveis para o Azure DevOps (anteriormente VSTS), veja Descrição geral das ferramentas de DevOps para o Azure DevOps.

Também pode utilizar o Kit de Teste de Carga (LTK) do SharePoint com VSTS para testes de carga de farms do SharePoint 2010. O Kit de Teste de Carga gera um teste de carga do Visual Studio Team System 2008 baseado no Windows SharePoint Services 3.0 e logs do Microsoft Office SharePoint Server 2007 IIS. O teste de carga do VSTS pode ser utilizado para gerar carga sintética no SharePoint Foundation 2010 ou no SharePoint Server 2010 como parte de um exercício de planeamento de capacidade ou de um teste de esforço de pré-atualização.

O Load Test Kit está incluído no Microsoft SharePoint 2010 Administration Toolkit v2.0, disponível no Centro de Transferências da Microsoft.

Um critério fundamental para o sucesso dos testes é conseguir simular eficazmente uma carga de trabalho realista ao gerar pedidos numa vasta gama de dados do site de teste, tal como os utilizadores acederiam a uma vasta gama de conteúdos num farm de produção do SharePoint Server 2013. Para tal, normalmente terá de construir os seus testes de forma a serem orientados por dados. Em vez de criar centenas de testes codificados para acessar uma página específica, use apenas alguns testes que utilizem fontes de dados contendo as URLs para esses itens acessarem dinamicamente o conjunto de páginas.

No Visual Studio Team System (Team Test Load Agent), uma origem de dados pode ter vários formatos, mas um formato de ficheiro CSV é frequentemente mais fácil de gerir e transportar entre ambientes de desenvolvimento e teste. Tenha em atenção que a criação de ficheiros CSV com esse conteúdo pode exigir a criação de ferramentas personalizadas para enumerar o ambiente baseado no SharePoint Server 2013 e registar os vários URLs que estão a ser utilizados.

Pode ser preciso usar ferramentas para tarefas como:

• Criar usuários e grupos no Active Directory ou outro armazenamento de autenticação se você estiver usando autenticação baseada em formulários

• Enumerar URLs para sites, listas e bibliotecas, itens de lista, documentos etc. e colocá-las em arquivos CSV para testes de carga

• Atualizar documentos de amostra através de uma variedade de bibliotecas e sites de documentos

• Criar conjuntos de sites, webs, listas, bibliotecas, pastas e itens de lista

• Criar Meus Sites

• Criar arquivos CSV com nomes de usuário e senhas para usuários de teste; essas são as contas de usuário como as quais os testes de carga executarão. Deve haver vários arquivos de modo que, por exemplo, alguns contenham somente usuários administradores, alguns contenham outros usuários com privilégios elevados (como autor/colaborador, gerente de hierarquia etc.) e outros sejam somente leitores, etc.

• Criar uma lista de palavras-chave e frases de pesquisa de amostra

• Preencher grupos do SharePoint e níveis de permissão com utilizadores e grupos do Active Directory (ou funções se estiver a utilizar a autenticação baseada em formulários)

Ao criar os teste web, há outras práticas recomendadas que você deve observar e implantar. Elas incluem:

• Registrar testes web simples como um ponto inicial. Esses testes terão valores hard-coded nos mesmos para parâmetros como URL, IDs, etc. Substitua esses valores hard-coded por ligações dos seus ficheiros CSV. O enlace de dados desses valores no Visual Studio Team System (Team Test Load Agent) é fácil.

• Sempre tenha regras de validação para o seu teste. Por exemplo, ao pedir uma página, se ocorrer um erro, receberá frequentemente a página error.aspx em resposta. Do ponto de vista do teste Web, aparece como apenas mais uma resposta positiva, porque obtém um código de estado HTTP de 200 (com êxito) nos resultados do teste de carga. Obviamente um erro ocorreu e isso deveria ser rastreado de maneira diferente. Criar uma ou mais regras de validação permite interceptar quando determinado texto é enviado como resposta, de modo que a validação falhe e a solicitação seja marcada como falha. Por exemplo, no Visual Studio Team System (Team Test Load Agent), uma regra de validação simples pode ser uma validação ResponseUrl. Regista uma falha se a página que é composta após redirecionamentos não for a mesma página de resposta que foi registada no teste. Também pode adicionar uma regra LocalizarTexto que registará uma falha se encontrar a palavra "acesso negado", por exemplo, na resposta.

• Use vários usuários em diferentes funções para testes. Certos comportamentos, como cache de saída, funcionam de maneira diferente dependendo dos direitos do usuário atual. Por exemplo, um administrador de coleções de sites ou um utilizador autenticado com direitos de aprovação ou de criação não obterá resultados em cache porque queremos que vejam sempre a versão mais atual do conteúdo. Usuários anônimos, porém, obterão conteúdo armazenado em cache. Você precisará garantir que seus usuários de teste sejam uma combinação dessas funções que corresponda aproximadamente à combinação de usuários no ambiente de produção. Por exemplo, na produção, existem provavelmente apenas dois ou três administradores de coleções de sites, pelo que não deve criar testes em que 10% dos pedidos de página são feitos por contas de utilizador que são administradores de coleções de sites através do conteúdo de teste.

• A análise de solicitações dependentes é um atributo de um Visual Studio Team System (Team Test Load Agent) que determina se o agente de teste deve tentar recuperar apenas a página, ou a página e todas as solicitações associadas que são parte da página, por exemplo, imagens, folhas de estilo, scripts etc. Ao realizar um teste de carga, normalmente ignoramos esses itens por alguns motivos:

  • Depois de um usuário acessar um site pela primeira vez, esses itens frequentemente são armazenados em cache pelo navegador local

  • Normalmente, estes itens não são provenientes do SQL Server num ambiente baseado no SharePoint Server 2013. Com a colocação em cache do BLOB ativada, são, em vez disso, servidos pelos servidores Web para que não gerem a carga do SQL Server.

Se você regularmente tiver uma alta percentagem de usuários estreando no seu site, ou tiver desativado armazenamento em cache do navegador, ou por algum motivo não pretender usar o cache BLOB, pode fazer sentido habilitar solicitações dependentes de análise nos seus testes. Porém, isso é realmente uma exceção e não a regra geral para a maioria das implantações. Saiba que se você ativar esse recurso, isso pode aumentar significativamente os números de RPS relatados pelo controlador de teste. Estes pedidos são servidos tão rapidamente que podem induzi-lo a pensar que há mais capacidade disponível no farm do que realmente existe.

• Lembre-se de modelar a atividade do aplicativo cliente também. As aplicações cliente, como o Microsoft Word, PowerPoint, Excel e Outlook, também geram pedidos para farms do SharePoint Server 2013. Eles adicionam carga ao ambiente enviando as solicitações do servidor como recuperar RSS feeds, adquirir informações sociais, solicitar detalhes sobre a estrutura de lista e site, sincronizar dados etc. Esses tipos de solicitações devem ser incluídos e modelados se você tiver esses clientes na sua implantação.

• Na maioria dos casos, um teste web deve conter somente uma única solicitação. É mais fácil ajustar e solucionar problemas do agente de teste e solicitações individuais se o teste contém apenas uma única solicitação. Normalmente, os testes Web terão de conter vários pedidos se a operação que está a simular for composta por vários pedidos. Por exemplo, para testar este conjunto de ações, precisará de um teste com vários passos: dar saída de um documento, editá-lo, dar entrada e publicá-lo. Também requer reservar o estado entre os passos . Por exemplo, a mesma conta de utilizador deve ser utilizada para dar saída, fazer as edições e dar entrada da mesma novamente. Essas operações de várias etapas que exigem estado para progredirem entre cada etapa são mais bem atendidas por várias solicitações em um único teste web.

• Avalie cada teste web individualmente. Garanta que cada teste seja capaz de concluir com sucesso antes de executá-lo em um teste de carga maior. Confirme se todos os nomes para aplicativos da web são resolvidos e se as contas de usuário utilizadas no teste têm direitos suficientes para executar o teste.

Testes web compreendem solicitações de páginas individuais, carregamento de documentos, visualização de itens de lista etc. Tudo isso é reunido em testes de carga. Um teste de carga é onde você conecta todos os diferentes testes web que serão executados. Cada teste Web pode receber uma percentagem de tempo que irá executar, por exemplo, se descobrir que 10% dos pedidos num farm de produção são consultas de pesquisa, no teste de carga, configuraria um teste Web de consulta para executar 10% do tempo. No Visual Studio Team System (Team Test Load Agent), os testes de carga também são como você configura elementos como combinação de navegadores, combinação de redes, padrões de carga e configurações de execução.

Há algumas práticas recomendadas adicionais que devem ser observadas e implantadas para testes de carga:

• Use uma proporção razoável de leitura/gravação nos seus testes. Sobrecarregar o número de gravações em um teste pode causar um impacto significativo sobre o rendimento geral do teste. Mesmo em farms de colaboração, as proporções de leitura/gravação tendem a ter muito mais leituras que gravações.

• Considere o impacto de outras operações com uso intenso de recursos e decida se elas devem ocorrer durante o teste de carga. Por exemplo, operações como backup e restauração geralmente não são feitas durante um teste de carga. Um rastreamento de pesquisa completo pode não ser normalmente executado durante um teste de carga, enquanto um rastreamento incremental pode ser normal. Tem de considerar como essas tarefas serão agendadas em produção. Serão executadas em picos de carga? Caso contrário, provavelmente devem ser excluídos durante o teste de carga, quando estiver a tentar determinar a carga máxima de estado estável que pode suportar para o tráfego de pico.

• Não use tempos de raciocínio. Os tempos de raciocínio são um recurso do Visual Studio Team System (Team Test Load Agent) que permitem simular o tempo que os usuários pausam entre cliques em uma página. Por exemplo, um usuário típico pode carregar uma página, passar três minutos lendo-a e então clicar em um link na página para visitar outro site. Tentar modelar isso corretamente em um ambiente de teste é quase impossível e, efetivamente, não agrega valor aos resultados do teste. É difícil de modelar porque a maioria das organizações não tem uma maneira de monitorar diferentes usuários e o tempo que eles passam entre cliques em diferentes tipos de sites do SharePoint (como publicação versus pesquisa versus colaboração, etc.). Também não acrescenta valor porque, apesar de um utilizador poder colocar em pausa entre pedidos de página, os servidores baseados no SharePoint Server 2013 não o fazem. Apenas recebem um fluxo constante de pedidos que podem ter picos e vales ao longo do tempo, mas não estão à espera de identidade enquanto cada utilizador pára entre clicar em ligações numa página.

• Entenda a diferença entre usuários e solicitações. O Visual Studio Team System (Team Test Load Agent) tem um padrão de carga em que pede que você insira o número de usuários para simular. Isto não tem nada a ver com os utilizadores da aplicação, é o número de threads que vão ser utilizados nos agentes de teste de carga para gerar pedidos. Um erro comum é pensar que, se a implementação tiver 5000 utilizadores, por exemplo, 5000 é o número que deve ser utilizado no Visual Studio Team System (Team Test Load Agent) – não é! Esse é um dos muitos motivos pelos quais, ao estimar as exigências de planejamento de capacidade, as exigências de uso devem ser baseadas no número de solicitações por segundo, e não no número de usuários. Num teste de carga do Visual Studio Team System (Team Test Load Agent), verá que, muitas vezes, pode gerar centenas de pedidos por segundo com apenas 50 a 75 "utilizadores" de teste de carga.

• Use um padrão de carga constante para resultados de teste mais confiáveis e reprodutíveis. No Visual Studio Team System (Team Test Load Agent), tem a opção de basear a carga num número constante de utilizadores (threads, conforme explicado no ponto anterior), um padrão de carga aumentado dos utilizadores ou um teste de utilização baseado em objetivos. Um padrão de carga em nível é quando você começa com um número menor de usuários e depois aumenta acrescentando mais usuários a cada alguns minutos. Um teste de uso baseado em objetivo é quando você estabelece um limite para um certo contador de diagnóstico, como utilização de CPU, e testa tentativas de conduzir a carga para manter o contador entre o limite mínimo e o máximo que você definiu. No entanto, se estiver apenas a tentar determinar o débito máximo que o farm do SharePoint Server 2013 pode suportar durante o pico de carga, é mais eficaz e preciso escolher apenas um padrão de carga constante. Isso permite identificar mais facilmente quanta carga o sistema pode assumir antes de começar a exceder regularmente os limites que devem ser mantidos em um farm saudável.

Sempre que executar um teste de carga, lembre-se de que está a alterar os dados na base de dados. Esteja carregando documentos, editando itens de lista ou apenas registrando atividade no banco de dados de uso, haverá dados gravados no SQL Server. Para garantir um conjunto consistente e legítimo de resultados de teste de cada teste de carga, você deve ter um backup disponível antes de executar o primeiro teste de carga. Após a conclusão de cada teste de carga, a cópia de segurança deve ser utilizada para restaurar o conteúdo novamente, foi antes de o teste ter sido iniciado.

Confira também

Conceitos

Planejamento de capacidade para o SharePoint Server 2013

Monitoramento e manutenção do SharePoint Server 2013

Limites de software para o SharePoint Server 2016

Outros recursos

Capacity management and sizing overview for SharePoint Server 2013