Teste de desempenho para SharePoint Server 2013

APLICA-SE A:yes-img-132013 no-img-16 2016no-img-192019 no-img-seSubscription Edition no-img-sopSharePoint 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 realizar testes de aceitação com as práticas recomendadas de monitoramento a fim de garantir que as arquiteturas que você projeta alcancem 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 do usuário dos novos recursos do SharePoint Server 2013, teste particularmente importante 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 alcançar 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 a pré-produção:

  • Criar o ambiente de teste que simule a arquitetura inicial projetada na Etapa 2: Projetar.

  • 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 a visão geral de gerenciamento 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 um código ou componente personalizado, é importante testar o desempenho desses componentes primeiro isoladamente para validar seu desempenho e estabilidade. Depois de eles estarem estáveis, você deve testar o sistema com os componentes instalados e comparar o desempenho para 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 de seu farm, por exemplo, você vai querer medir o RPS e a latência de página. Se você estiver medindo o desempenho da pesquisa, precisará 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á Active Directory Domain Services (AD DS), autenticação baseada em formulários (e, se usar, com qual diretório), autenticação baseada em declarações etc. Independentemente do diretório que você está usando, de quantos usuários você precisa no ambiente de teste e como irá criá-los? 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 de que você precisará durante o teste. Identifique que servidores responderão a essas solicitações e inclua um plano que indique que endereços IP serão usados por quais servidores e de que entradas de DNS você precisará criar.

  • Balanceamento de carga: presumindo que você está usando mais de um servidor (o que normalmente fará, caso contrário, não terá carga suficiente para justificar um teste de carga), você precisa de algum tipo de solução balanceadora de carga. Essa pode ser um dispositivo de balanceamento de carga ou você pode usar um software de balanceamento de carga, como Windows NLB. Determine o que você usará e anote todas as informações de configuração de que precisará para configurar a solução de maneira rápida e eficiente. Outro ponto a lembrar é que agentes de teste de carga normalmente tentam resolver o endereço para uma URL apenas uma vez a cada 30 minutos. Isso significa que você não deve usar um arquivo de hosts local ou DNS de rodízio para balanceamento de carga porque os agentes de teste provavelmente terminarão indo para o mesmo servidor para todas as solicitações, em vez de balancear através de todos os servidores disponíveis.

  • Servidores de teste: ao planejar seu ambiente de teste, você não só precisa planejar os servidores para o farm do SharePoint Server 2013, como também precisa 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ê está usando o Visual Studio Team System (Team Test Load Agent) para fazer o teste, uma máquina é usada como o controlador de teste de carga. Geralmente há dois ou mais computadores que são usados como agentes de teste de carga. Os agentes são os computadores que tomam as instruções do controlador de teste sobre o que testar e emitir 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 em SQL Server que é usado para o farm do SharePoint Server 2016, pois a gravação dos dados de teste distorcerá os recursos de SQL Server disponíveis 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, então a taxa de transferência, você verá que em seu teste normalmente não é o farm máximo que pode dar suporte.

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

  • Validação do conjunto de dados: ao decidir sobre com que conteúdo executará testes, lembre-se de que no melhor cenário 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 de quantos grupos e/ou níveis de permissão do SharePoint você precisará e como irá 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 precisará de fontes de conteúdo de pesquisa adicionais e do que precisará 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 - para bibliotecas de documentos diferentes 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, é 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 do DevOps para o Azure DevOps.

Você também pode usar o LTK (Kit de Teste de Carga) do SharePoint com o VSTS para testes de carga das fazendas 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 VSTS pode ser usado para gerar carga sintética com 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.

O Kit de Teste de Carga está incluído no Kit de Ferramentas de Administração do Microsoft SharePoint 2010 v2.0, disponível no Centro de Download da Microsoft.

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 gama de dados do site de teste, assim como os usuários acessariam uma ampla gama de conteúdo em um farm de produção do SharePoint Server 2013. Para fazer isso, você normalmente precisará construir seus testes de modo que sejam conduzidos 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 formados, mas um formato de arquivo CSV frequentemente é mais fácil de gerenciar e transportar entre ambientes de teste e desenvolvimento. Tenha em mente 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

  • Preencher níveis de permissão e grupos do SharePoint 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 codificados para parâmetros como URL, IDs etc. Substitua esses valores codificados por links dos seus arquivos CSV. Fazer a ligação de dados desses valores no Visual Studio Team System (Team Test Load Agent) é extremamente fácil.

  • Sempre tenha regras de validação para o seu teste. Por exemplo, ao solicitar uma página, se ocorrer um erro, você frequentemente obterá a página error.aspx em resposta. De uma perspectiva de teste web, ele 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 redirecionamentos não for a mesma página de resposta registrada no teste. Você também pode adicionar uma regra FindText que registrará uma falha se encontrar a expressão "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 direitos de aprovação ou criação não obterá resultados armazenados em cache porque sempre queremos que eles vejam as versão mais atualizada 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, em produção, há provavelmente apenas dois ou três administradores de conjuntos de sites, assim, você não deve criar testes em que 10% das solicitações de página sejam feitas por contas de usuário de 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

    • Esses itens normalmente não vêm de SQL Server em um ambiente baseado no SharePoint Server 2013. Com armazenamento em cache BLOB ativado, eles são, em vez disso, atendidos pelos servidores web, de modo que não geram carga ao 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 levá-lo a pensar erroneamente que há mais capacidade disponível no farm do que de fato há.

  • 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 fazendas 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. Testes web normalmente precisam conter várias solicitações se a operação que está simulando é composta de várias solicitações. Por exemplo, para testar esse conjunto de ações, você precisa de um teste com várias etapas: fazer check-out de um documento, editá-lo, fazer o check-in e publicá-lo. Ele também requer o estado de reserva entre as etapas - por exemplo, a mesma conta de usuário deve ser usada para verificar, fazer as edições e fazer check-in 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 porcentagem de tempo que ele executará - por exemplo, se você descobrir que 10% das solicitações em um farm de produção são consultas de pesquisa, então no teste de carga você configurará 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. Você precisa considerar como essas tarefas serão agendadas na produção - elas serão executadas em horários de pico de carga? Se a resposta for não, elas provavelmente devem ser excluídas durante o teste de carga, em que você está tentando determinar a carga de estado contínuo máxima que pode suportar para o pico 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 solicitações de página, os servidores baseados no SharePoint Server 2013 não. Eles recebem um fluxo contínuo de solicitações que podem ter picos e declives ao longo do tempo, mas não fica esperando ociosamente enquanto cada usuário pausa entre os cliques nos 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 nenhuma relação com usuários do aplicativo, na verdade, é apenas quantos threads serão usados nos agentes do teste de carga para gerar solicitações. Um erro comum é pensar que, se a implantação tiver 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ê verá que pode frequentemente gerar centenas de solicitações por segundo usando apenas de 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 carga intensificado dos 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 apenas escolher 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 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. Depois que cada teste de carga for concluído, o backup deve ser usado para restaurar o conteúdo de volta ao caminho, foi antes do teste ser 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