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. Você deve testar novas arquiteturas antes de implantá-las na produção e deve realizar testes de aceitação com as seguintes práticas recomendadas de monitoramento para garantir que as arquiteturas projetadas atinjam as metas 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 você estiver atualizando de um ambiente do Office SharePoint Server 2007 e planeja fazer alterações arquitetônicas ou está estimando a carga de usuários dos novos recursos do SharePoint Server 2013, é importante testar para garantir que seu novo ambiente baseado no SharePoint Server 2013 atenda às metas de desempenho e capacidade.

Depois de testar seu ambiente, você pode analisar os resultados do teste para determinar quais alterações precisam ser feitas para atingir as metas de desempenho e capacidade estabelecidas na Etapa 1: Modelo de planejamento de capacidade para o SharePoint Server 2013.

Estas são as subetapas recomendadas que você deve seguir para 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, você deve ler Visão geral do dimensionamento e gerenciamento de capacidade 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 você tiver um código personalizado ou um componente personalizado, é importante testar o desempenho desses componentes isoladamente primeiro para validar seu desempenho e estabilidade. Depois que eles estiverem estáveis, você deve testar o sistema com esses componentes instalados e comparar o desempenho com o farm sem eles 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 você estiver interessado em medir a capacidade de taxa de transferência do seu farm, por exemplo, convém medir o RPS e a latência da página. Se você estiver medindo o desempenho da pesquisa, convém medir o tempo de rastreamento 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 usará o AD DS (Active Directory Domain Services), autenticação baseada em formulários (e, em caso afirmativo, com qual diretório), autenticação baseada em declarações etc. Independentemente de qual diretório você está usando, quantos usuários você precisa em seu ambiente de teste e como você os 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 namespaces necessários durante o teste. Identifique quais servidores responderão a essas solicitações e certifique-se de ter incluído um plano com quais endereços IP serão usados por quais servidores e quais entradas DNS você precisará criar.

• Balanceamento de carga: Supondo que você esteja usando mais de um servidor (o que normalmente faria ou provavelmente não teria carga suficiente para justificar o teste de carga), você 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 você usará e anote todas as informações de configuração necessárias para configurá-lo de forma rápida e eficiente. Outra coisa a lembrar é que os agentes de teste de carga normalmente tentam resolver o endereço para um URL apenas uma vez a cada 30 minutos. Isso significa que você não deve usar um arquivo hosts local ou DNS round robin para balanceamento de carga porque os agentes de teste provavelmente acabarão indo para o mesmo servidor para cada solicitação, em vez de balancear em torno de todos os servidores disponíveis.

• Servidores de teste: ao planejar seu ambiente de teste, você não só precisa planejar os servidores do farm do SharePoint Server 2013, mas também planejar os computadores necessários para executar os testes. Normalmente, isso incluirá três servidores no mínimo; mais pode ser necessário. Se você estiver usando o Visual Studio Team System (Team Test Load Agent) para fazer o teste, um computador será usado como controlador de teste de carga. Geralmente, há duas ou mais máquinas que são usadas como agentes de teste de carga. Os agentes são as máquinas que recebem as instruções do controlador de teste sobre o que testar e emitem as solicitações para o farm do SharePoint Server 2013. Os resultados do teste em si são armazenados em um computador baseado em SQL Server. Você não deve usar o mesmo computador baseado no SQL Server que é usado para o farm do SharePoint Server 2016, pois gravar os dados de teste distorcerá os recursos disponíveis do SQL Server para o farm do SharePoint Server 2013. Você também precisa monitorar seus servidores de teste ao executar seus testes, da mesma forma que monitoraria os servidores no farm do SharePoint Server 2013, ou controladores de domínio, etc., para garantir que os resultados do teste sejam representativos do farm que você está configurando. Às vezes, os agentes ou o controlador de carga podem eles próprios se tornar o gargalo. Se isso acontecer, a taxa de transferência que você vê em seu teste normalmente não é a máxima que o farm pode suportar.

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

• Validação do conjunto de dados: ao decidir em qual conteúdo você executará os testes, lembre-se de que, na melhor das hipóteses, você usará 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 do SharePoint e/ou níveis de permissão você vai precisar e como você vai associar usuários a eles.

• 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 você precisa de mais fontes de conteúdo de pesquisa e o que será necessário para criá-las. Se não precisar criá-las, determine se terá acesso de rede para poder rastreá-las.

• Determine se você tem dados de exemplo suficientes - documentos, listas, itens de lista etc. Caso contrário, crie um plano de como você criará esse 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 até milhares de vezes, em 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 que o ambiente de teste estiver funcional, é hora de criar e ajustar os testes que serão usados 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 (antigo VSTS), consulte Visão geral das ferramentas de DevOps para o Azure DevOps.

Você também pode usar o Kit de Teste de Carga do SharePoint (LTK) com VSTS para teste 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 usado para gerar carga sintética em relação ao SharePoint Foundation 2010 ou ao SharePoint Server 2010 como parte de um exercício de planejamento de capacidade ou um teste de estresse pré-atualização.

Um critério fundamental para o sucesso dos testes é ser capaz de simular efetivamente uma carga de trabalho realista gerando solicitações em uma ampla variedade de dados do site de teste, assim como os usuários acessariam uma ampla variedade de conteúdo em um farm de produção do SharePoint Server 2013. Para fazer isso, você normalmente precisará construir seus testes de forma que eles sejam 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 fonte de dados pode vir em vários formatos, mas um formato de arquivo CSV geralmente é mais fácil de gerenciar e transportar entre ambientes de desenvolvimento e teste. Lembre-se de que a criação de arquivos CSV com esse conteúdo pode exigir a criação de ferramentas personalizadas para enumerar o ambiente baseado no SharePoint Server 2013 e registrar as várias URLs que estão sendo usadas.

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

• Preenchendo grupos do SharePoint e níveis de permissão com usuários e grupos do Active Directory (ou funções, se você estiver usando 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 embutidos no código para parâmetros como URL, IDs, etc. Substitua esses valores embutidos em código por links de seus arquivos CSV. A associação 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 solicitar uma página, se ocorrer um erro, você geralmente receberá a página error.aspx em resposta. De uma perspectiva de teste na Web, ela aparece como apenas mais uma resposta positiva, pois você obtém um código de status HTTP de 200 (bem-sucedido) 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 - ela registra uma falha se a página renderizada após os redirecionamentos não for a mesma página de resposta que foi registrada no teste. Você também pode adicionar uma regra FindText que registrará 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 conjunto de sites ou um usuário autenticado com aprovação ou direitos de criação não obterá resultados armazenados em cache porque sempre queremos que eles vejam 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, provavelmente há apenas dois ou três administradores de conjunto de sites, portanto, você não deve criar testes em que 10% das solicitações de página são feitas por contas de usuário que são administradores de conjunto de sites sobre o 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, esses itens não vêm do SQL Server em um ambiente baseado no SharePoint Server 2013. Com o cache de BLOB ativado, eles são atendidos pelos servidores Web para que não gerem 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. Essas solicitações são atendidas tão rapidamente que podem induzi-lo a pensar que há mais capacidade disponível na fazenda do que realmente existe.

• Lembre-se de modelar a atividade do aplicativo cliente também. Aplicativos cliente, como Microsoft Word, PowerPoint, Excel e Outlook, também geram solicitações 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. Os testes na Web normalmente precisarão conter várias solicitações se a operação que está simulando for composta de várias solicitações. Por exemplo, para testar esse conjunto de ações, você precisará de um teste com várias etapas: fazer check-out de um documento, editá-lo, fazer check-in e publicá-lo. Também requer reservar o estado entre as etapas - por exemplo, a mesma conta de usuário deve ser usada para marcar-lo, fazer as edições e marcar-lo 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 da Web pode receber uma porcentagem de tempo que será executado - por exemplo, se você descobrir que 10% das solicitações em um farm de produção são consultas de pesquisa, no teste de carga você configuraria um teste da Web de consulta para ser executado 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. Você precisa considerar como essas tarefas serão agendadas na produção - elas serão executadas em horários de pico de carregamento? Caso contrário, eles provavelmente devem ser excluídos durante o teste de carga, quando você está tentando determinar a carga máxima de estado estável que pode suportar para picos de tráfego.

• 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.). Ele também não agrega valor porque, embora um usuário possa pausar entre as solicitações de página, os servidores baseados no SharePoint Server 2013 não. Eles apenas recebem um fluxo constante de solicitações que podem ter picos e vales ao longo do tempo, mas não estão esperando ociosamente enquanto cada usuário faz uma pausa entre clicar em links em uma 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. Isso não tem nada a ver com usuários de aplicativos, é apenas quantos threads serão usados nos agentes de teste de carga para gerar solicitações. Um erro comum é pensar que se a implantação terá 5.000 usuários, por exemplo, 5.000 é o número que deve ser usado 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. Em um teste de carga do Visual Studio Team System (Team Test Load Agent), você descobrirá que geralmente pode gerar centenas de solicitações por segundo usando apenas 50 a 75 "usuários" 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), você tem a opção de basear a carga em um número constante de usuários (threads, conforme explicado no ponto anterior), um padrão de carregamento avançado de usuários ou um teste de uso baseado em meta. 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 você estiver apenas tentando determinar a taxa de transferência máxima que seu farm do SharePoint Server 2013 pode sustentar 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 você executar um teste de carga, lembre-se de que ele está alterando os dados no banco 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, o backup deve ser usado para restaurar o conteúdo de volta ao modo como era antes do início do teste.

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