Testes de desempenho para SharePoint Server 2010

Artigo
03/07/2017

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve como testar o desempenho do Microsoft SharePoint Server 2010. A fase de testes e otimização é um componente crucial do gerenciamento de capacidade efetivo. Você deve testar novas arquiteturas antes de implantá-las em produção e deve realizar testes de aceitação em conjunto com as práticas recomendadas de monitoramento a seguir, para garantir que as arquiteturas que você projetar cumpram as metas de desempenho e capacidade. Isso permite identificar e otimizar afunilamentos em potencial antes que eles afetem os usuários em uma implantação dinâmica. Se você estiver atualizando de um ambiente do Microsoft Office SharePoint Server 2007 e planejar alterações na arquitetura ou se estiver estimando a carga do usuário dos novos recursos do SharePoint Server 2010, os testes serão particularmente importantes para garantir que o novo ambiente baseado no SharePoint Server 2010 cumpra as metas de desempenho e capacidade.

Após testar o ambiente, você pode analisar os resultados do teste para determinar as alterações que precisam ser feitas de modo a cumprir as metas de desempenho e capacidade que você estabeleceu na Etapa 1: Modelo de Planejamento de capacidade para SharePoint Server 2010.

Estas são as subetapas recomendadas para a pré-produção:

Criar o ambiente de teste que reflete a arquitetura inicial projetada por você em Etapa 2: Design.
Popular o armazenamento com o conjunto de dados ou parte do conjunto de dados que você identificou na Etapa 1: Modelo.
Realizar um teste de estresse do sistema com uma carga sintética que representa a carga de trabalho que você identificou na Etapa 1: Modelo.
Executar testes, analisar os resultados e otimizar arquitetura.
Implantar a arquitetura otimizada no data center e introduzir um piloto com um conjunto de usuários menor.
Analisar os resultados do piloto, identificar possíveis afunilamentos 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 gerenciamento da capacidade e dimensionamento do SharePoint Server 2010.

Neste artigo:

Criar um plano de teste
Criar o ambiente de teste
Crie testes e ferramentas

Criar um plano de teste

Verifique se o plano inclui:

Hardware projetado para operar de acordo com as metas de desempenho de produção esperadas. Sempre meça o desempenho dos sistemas de teste de forma cautelosa.
Se você tem um componente ou código personalizado, é importante testar primeiro o desempenho desses componentes em isolamento para validar seu desempenho e estabilidade. Depois que eles estiverem estáveis, você deverá testar o sistema com os componentes instalados e comparar o desempenho com o farm sem esses itens instalados. Componentes personalizados frequentemente são uma das principais causas de problemas de desempenho e confiabilidade em sistemas de produção.
Conheça o objetivo dos testes. Entenda antecipadamente quais são seus objetivos de testes. Eles se destinam a validar o desempenho de alguns novos componentes personalizados que foram desenvolvidos para o farm? Você deseja verificar quanto tempo levará para rastrear e indexar um conjunto de conteúdo? É necessário determinar a quantas solicitações por segundo o farm pode dar suporte? Pode haver muitos objetivos diferentes durante um teste, e a primeira etapa no desenvolvimento de um bom plano de teste consiste em decidir quais são seus objetivos.
Entenda como medir sua meta de teste. Se você estiver interessado em medir a capacidade de produtividade do farm, por exemplo, convém medir o RPS e a latência de página. Se estiver medindo o desempenho de pesquisa, convém medir o tempo de rastreamento e as taxas de indexação de documentos. Se o seu objetivo de testes for bem entendido, isso o ajudará a definir claramente os principais indicadores de desempenho que você precisará validar para concluir os testes.

Criar o ambiente de teste

Depois que os objetivos de teste tiverem sido decididos, as medidas tiverem sido definidas e você tiver determinado os requisitos de capacidade do farm (nas etapas 1 e 2 deste processo), o próximo objetivo será projetar e criar o ambiente de teste. O esforço para criar um ambiente de teste é muitas vezes subestimado. Ele deve duplicar o ambiente de produção, tanto quanto possível. Alguns dos recursos e funcionalidade que você deve considerar ao projetar o ambiente de teste são:

Autenticação – Decida se o farm usará o AD DS (Serviços de Domínio Active Directory), autenticação baseada em formulários (e, em caso afirmativo, com qual diretório), autenticação baseada em declarações etc. Independentemente do diretório que você estiver usando, quantos usuários serão necessários no ambiente de teste e como você os criará e populará? Quantos grupos ou funções serão necessários e como você os criará e populará? Também é preciso garantir que haja recursos suficientes alocados para os serviços de autenticação, para que eles não se tornem um afunilamento durante o teste.
DNS – Saiba quais são os namespaces de que você necessitará durante os testes. Identifique os servidores que responderão às solicitações. Verifique se incluiu um plano com os endereços IP que serão usados por cada servidor e quais entradas DNS você terá de criar.
Balanceamento de carga – Pressupondo que você esteja usando mais de um servidor (o que normalmente seria o caso, ou você provavelmente não teria carga suficiente para justificar os testes de carga), será necessário algum tipo de solução de balanceamento de carga. Pode se tratar de um dispositivo de balanceamento de carga de hardware ou você pode usar balanceamento de carga de software, como o Windows NLB. Determine a opção que você utilizará e anote todas as informações de configuração de que precisará para configurá-la de forma rápida e eficiente. Outro item a ser lembrado é que, geralmente, os agentes de teste de carga 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 o DNS round robin para balanceamento de carga, pois os agentes de teste provavelmente acabarão indo para o mesmo servidor para cada solicitação, em vez de equilibrar a carga entre todos os servidores disponíveis.
Servidores de teste – Ao planejar o ambiente de teste, além de precisar planejar os servidores para o farm do SharePoint Server 2010, você também precisa planejar os computadores necessários para executar os testes. Tipicamente, isso incluirá três servidores, no mínimo, pode ser necessário um número maior. Se você estiver usando o Visual Studio Team System (Team Test Load Agent) para realizar o teste, um computador será utilizado como controlador de teste de carga. Geralmente há dois ou mais computadores que são utilizados como agentes de teste de carga. Os agentes são os computadores que obtêm as instruções do controlador de teste sobre o que deve ser testado e emitem as solicitações para o farm do SharePoint Server 2010. Os resultados do teste são armazenados em um computador baseado no SQL Server. Você não deve usar o mesmo computador baseado no SQL Server que é usado para o farm do SharePoint Server 2010, pois a gravação dos dados de teste distorcerá os recursos disponíveis do SQL Server para o farm do SharePoint Server 2010. Também é preciso monitorar os servidores de teste ao executar os testes, da mesma forma como você monitoraria os servidores no farm do SharePoint Server 2010 ou controladores de domínio etc., para garantir que os resultados do teste sejam representativos do farm que você está configurando. Às vezes, os próprios agentes de carga ou o o próprio controlador podem se tornar o afunilamento. Se isso ocorrer, a produtividade indicada no teste normalmente não será o máximo ao qual o farm pode dar suporte.
SQL Server – No ambiente de teste, siga as diretrizes das 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 armazenamento e capacidade do SQL Server (SharePoint Server 2010).
Validação do conjunto de dados – Ao decidir o conteúdo em relação ao qual 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, é possível fazer backup dos bancos de dados de conteúdo de um farm de produção, restaurá-los no ambiente de teste e, em seguida, anexar os bancos de dados para levar o conteúdo para o farm. Sempre que executa testes com dados de amostra ou fictícios, você corre o risco de obter resultados distorcidos, devido às diferenças no corpus de conteúdo.

Se for necessário criar dados de exemplo, você deverá ter em mente algumas considerações ao criar o conteúdo:

Todas as páginas devem ser publicadas; não deve ser feito check-out de nada
A navegação deve ser realista; não crie um volume superior ao que seria razoável esperar para o uso na produção.
Você deve ter uma ideia das personalizações que o site de produção usará. Por exemplo, páginas mestras, folhas de estilo, JavaScript etc. devem ser implementados no ambiente de teste da maneira mais semelhante possível ao ambiente de produção.
Determine de quantos grupos do SharePoint e/ou níveis de permissão você precisará e como associará usuários a eles.
Determine se precisará realizar importações de perfil e quanto tempo isso levará.
Determinar se precisará de Audiências e como as criará e populará.
Determine se precisará de fontes de conteúdo de pesquisa adicionais e o que será necessário para criá-las. Se não for preciso criá-las, determine se você terá acesso à rede para poder rastreá-las.
Determine se você tem dados de amostra suficientes – documentos, listas, itens de lista etc. Se não tiver, crie um plano para a maneira como você criará esse conteúdo.
Tenha um plano para garantir que haja conteúdo exclusivo suficiente para testar a pesquisa de forma adequada. Um erro comum é carregar o mesmo documento – talvez centenas ou mesmo milhares de vezes – para bibliotecas de documentos diferentes com nomes diferentes. Isso pode afetar o desempenho de pesquisa, pois o processador de consultas gastará tempo excessivo com a detecção de duplicatas, o que não ocorreria em um ambiente de produção com o conteúdo real.

Crie testes e ferramentas

Depois que o ambiente de teste estiver funcional, será o momento de criar e ajustar os testes que serão utilizados para medir a capacidade de desempenho do farm. Esta seção fará algumas referências especificamente ao Visual Studio Team System (Team Test Load Agent), mas muitos dos conceitos são aplicáveis independentemente da ferramenta de teste de carga que você usar. Para obter mais informações sobre o Visual Studio Team System, consulte Visual Studio Team System at MSDN (https://msdn.microsoft.com/pt-br/library/fda2bad5.aspx" ).

Você também pode usar o LTK (Kit de Teste de Carga) do SharePoint em conjunto com o 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 em logs do IIS do Windows SharePoint Services 3.0 e do Microsoft Office SharePoint Server 2007. O teste de carga do VSTS pode ser usado para gerar carga sintética em relação ao SharePoint Foundation 2010 ou 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 Microsoft SharePoint 2010 Administration Toolkit v1.0, disponível no Centro de Download da Microsoft (https://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en).

Um critério fundamental para o sucesso dos testes consiste em poder simular efetivamente uma carga de trabalho realista, mediante a geração de solicitações em uma ampla gama dos dados de site de teste, assim como os usuários acessariam uma ampla gama de conteúdo em um farm de produção do SharePoint Server 2010. Para fazer isso, normalmente você precisará criar os testes de tal forma que eles sejam controlados por dados. Em vez de criar centenas de testes individuais embutidos em código para o acesso a uma página específica, você deve usar apenas alguns testes que utilizem fontes de dados contendo as URLs dos itens para acessar dinamicamente o conjunto de páginas.

No Visual Studio Team System (Team Test Load Agent), uma fonte de dados pode ter diversos formatos, mas o formato de arquivo CSV geralmente é o mais fácil de gerenciar e transportar entre ambientes de desenvolvimento e de 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 em SharePoint Server 2010 e registrar as várias URLs que estão sendo usadas.

Talvez você precise usar ferramentas para tarefas como:

Criar usuários e grupos no Active Directory ou outro repositório de autenticação, se você estiver usando autenticação baseada em formulários
Enumerar URLs de sites, listas e bibliotecas, itens de lista, documentos etc. e colocá-las em arquivos CSV para testes de carga
Carregar documentos de exemplo em diversas bibliotecas de documentos e sites
Criar conjuntos de sites, webs, listas, bibliotecas, pastas e itens de lista
Criando 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 com as quais os testes de carga serão executados. Deve haver vários arquivos, de modo que, por exemplo, alguns contenham apenas usuários administradores, outros contenham outros usuários com privilégios elevados (como autor/parceiro, gerente de hierarquia etc.) e outros sejam apenas leitores etc.
Criar uma lista de palavras-chave e frases de pesquisa de exemplo
Popular grupos do SharePoint e níveis de permissão com usuários e grupos do Active Directory (ou funções, se você estiver usando a autenticação baseada em formulários)

Ao criar os testes da Web, há outras práticas recomendadas que você deve observar e implementar. São elas:

Grave testes da Web simples como ponto de partida. Esses testes conterão valores embutidos em código para parâmetros como URL, IDs etc. Substitua os valores embutidos em código por links dos arquivos CSV. A vinculaçã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 teste. Por exemplo, ao ser solicitada uma página, se ocorrer um erro, muitas vezes você obterá a página error.aspx como resposta. De uma perspectiva de teste da Web, essa parece ser apenas outra resposta positiva, pois você obtém um código de status HTTP 200 (bem-sucedido) nos resultados do teste de carga. Contudo, obviamente ocorreu um erro; portanto, isso deve ser rastreado de forma diferente. A criação de uma ou mais regras de validação permite que você intercepte quando determinado texto é enviado como resposta, para que a validação falhe e a solicitação seja marcada como tendo sofrido uma falha. Por exemplo, no Visual Studio Team System (Team Test Load Agent), uma regra de validação simples poderia ser uma validação responseURL – ela gravará uma falha se a página que é renderizada após redirecionamentos não for a mesma página de resposta que foi gravada no teste. Você também pode adicionar uma regra FindText que gravará uma falha se encontrar as palavras "acesso negado ", por exemplo, na resposta.
Use vários usuários em diferentes funções para os testes. Certos comportamentos, como o cache de saída, funcionam de forma 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ão resultados armazenados em cache, pois sempre queremos que eles vejam a versão mais atual do conteúdo. Usuários anônimos, no entanto, obterão o conteúdo armazenado em cache. Você precisa garantir que os usuários de teste constituam uma mistura dessas funções, correspondendo aproximadamente à mistura de usuários no ambiente de produção. Por exemplo, na produção, provavelmente há apenas dois ou três administradores de conjuntos de sites; portanto, você não deve criar testes em que 10% das solicitações de página sejam feitos por contas de usuários de administradores de conjuntos de sites para 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 fazem parte dela, como imagens, folhas de estilo, scripts etc. Nos testes de carga, geralmente esses itens são ignorados por algumas razões:
- Depois que um usuário acessa um site pela primeira vez, esses itens geralmente são armazenados em cache pelo navegador local
- Esses itens normalmente não vêm do SQL Server em um ambiente baseado no SharePoint Server 2010. Com o cache BLOB ativado, eles são atendidos pelos servidores Web, em vez disso, para que não gerem carga do SQL Server.

Se você tem regularmente uma alta porcentagem de usuários de primeira vez em seu site, se desabilitou o cache do navegador ou se, por algum motivo, não pretende usar o cache BLOB, talvez faça sentido habilitar a análise de solicitações dependentes nos testes. No entanto, essa é realmente uma exceção, não a regra para a maioria das implementações. Lembre-se de que se, você ativar esse recurso, isso poderá 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, enganadamente, que há mais capacidade disponível no farm do que a capacidade real.

Lembre-se de modelar também a atividade de aplicativos cliente. Aplicativos cliente, como Microsoft Word, PowerPoint, Excel e Outlook, também geram solicitações para farms do SharePoint Server 2010. Eles adicionam carga ao ambiente enviando ao servidor solicitações como recuperação de RSS feeds, aquisição de informações sociais, solicitação de detalhes sobre estrutura de sites e listas, sincronização de dados etc. Esses tipos de solicitações deverão ser incluídos e modelados se você tiver esses clientes em sua implementação.
Na maioria dos casos, um teste da Web deve conter uma única solicitação. É mais fácil ajustar e solucionar problemas do agente de teste e solicitações individuais se o teste contém uma única solicitação. Os testes da Web normalmente precisam conter várias solicitações quando a operação que estão simulando é composta por várias solicitações. Por exemplo, para testar esse conjunto de ações, você precisará de um teste com diversas etapas: fazer check-out de um documento, editá-lo, fazer check-in dele e publicá-lo. Também é necessário o estado de reserva entre as etapas – por exemplo, a mesma conta de usuário deve ser usada para fazer o check-out, realizar as edições e fazer o check-in do documento. Para operações com várias etapas que exigem que o estado seja mantido entre cada etapa, a melhor opção é utilizar várias solicitações em um único teste da Web.
Teste cada teste da Web individualmente. Verifique se cada teste pode ser concluído com êxito antes de executá-lo em um teste com carga maior. Confirme se todos os nomes de aplicativos Web são resolvidos e se as contas de usuário usadas no teste têm direitos suficientes para executar o teste.

Testes da Web incluem as solicitações de páginas individuais, o carregamento de documentos, a exibição de itens de lista etc. Todos esses itens são reunidos em testes de carga. Um teste de carga é aquele em que você reúne todos os diferentes testes da Web que serão executados. Pode ser atribuída uma porcentagem de tempo para a execução de cada teste da Web – por exemplo, se verificasse 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 por 10% do tempo. No Visual Studio Team System (Team Test Load Agent), os testes de carga também são usados para configurar itens como combinação de navegadores, combinação de redes, padrões de carga e configurações de execução.

Existem algumas práticas recomendadas adicionais que devem ser observadas e implementadas nos testes de carga:

Use uma taxa razoável de leitura/gravação nos testes. A sobrecarga do número de gravações em um teste pode afetar significativamente a produtividade global do teste. Mesmo em farms de colaboração, as taxas de leitura/gravação costumam ter muito mais leituras do que gravações. Para obter mais informações, consulte Performance and capacity technical case studies (SharePoint Server 2010).
Considere o impacto de outras operações com uso intensivo 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 realizadas durante um teste de carga. Normalmente, um rastreamento de pesquisa completo pode não ser 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? Se não forem, então provavelmente deverão ser excluídas durante os testes de carga, quando você tentará determinar a carga de estado estável máxima à qual pode dar suporte para o tráfego de pico.
Não use tempos de raciocínio. Tempos de raciocínio são um recurso do Visual Studio Team System (Team Test Load Agent) que permite simular o tempo de pausa dos usuários entre os cliques em uma página. Por exemplo, um usuário típico pode carregar uma página, lê-la por três minutos e, em seguida, clicar em um link nela para visitar outro site. É quase impossível tentar modelar isso corretamente em um ambiente de teste e, de fato, não é agregado valor ao resultado do teste. É algo difícil de modelar porque a maioria das organizações não tem uma maneira de monitorar usuários diferentes e o tempo que eles gastam entre cliques em diferentes tipos de sites do SharePoint (como publicação versus pesquisa versus colaboração etc.) Isso também não agrega valor porque, embora um usuário possa fazer uma pausa entre solicitações de página, os servidores baseados no SharePoint Server 2010 não o fazem. Simplesmente recebem um fluxo constante de solicitações que podem ter altos e baixos ao longo do tempo, mas eles não permanecem ociosos aguardando enquanto cada usuário faz uma pausa entre os cliques 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ê digite o número de usuários para a simulação. Isso não tem relação alguma com os usuários do aplicativo; trata-se apenas do número de threads que 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, então 5000 é o número que deverá ser usado no Visual Studio Team System (Team Test Load Agent) – não é! Essa é uma das muitas razões pelas quais, ao serem estimados os requisitos de planejamento de capacidade, os requisitos de uso devem ser baseados no número de solicitações por segundo, 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, muitas vezes, é possível gerar centenas de solicitações por segundo usando apenas 50 a 75 "usuários" do teste de carga.
Use um padrão de carga constante para obter os resultados de testes mais confiáveis e reproduzí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 de nível de usuários ou um teste de uso baseado em metas. Um padrão de carga de nível é aquele em que você começa com um número menor de usuários e, em seguida, "sobe um nível" adicionando usuários a cada poucos minutos. Um teste de uso com base em metas é aquele em que você estabelece um limite para um contador de diagnóstico, como utilização de CPU, e testa as tentativas para direcionar a carga de modo a manter esse contador entre os limites mínimo e máximo que você define para ele. No entanto, se você estiver apenas tentando determinar a produtividade máxima que o farm do SharePoint Server 2010 pode sustentar durante a carga de pico, será mais eficaz e preciso selecionar apenas um padrão de carga constante. Isso permite identificar mais facilmente a quantidade de carga que o sistema pode aceitar antes de começar a exceder regularmente os limites que devem ser mantidos em um farm íntegro.

Sempre que executar um teste de carga, lembre-se de que ele está alterando dados no banco de dados. Independentemente de se tratar de carregamento de documentos, edição de itens de lista ou apenas registro de atividade no banco de dados de uso, dados serão gravados no SQL Server. Para garantir um conjunto consistente e legítimo de resultados de teste em 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 deverá ser usado para restaurar o conteúdo de volta à maneira como era antes de ser iniciado o teste.

Share via

Testes de desempenho para SharePoint Server 2010

Criar um plano de teste

Criar o ambiente de teste

Crie testes e ferramentas

See Also

Concepts

Recursos adicionais