Estimar os requisitos de desempenho e capacidade dos Serviços PerformancePoint

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2017-01-18

Este artigo descreve o efeito que o uso do Serviços do PerformancePoint tem sobre topologias que executam o Microsoft SharePoint Server 2010.

Neste artigo:

• Características do farm de teste

• Resultados do teste

• Recomendações

Para obter informações gerais sobre como planejar e executar o planejamento da capacidade para o SharePoint Server 2010, consulte Capacity management and sizing for SharePoint Server 2010.

Características do farm de teste

Conjunto de dados

O conjunto de dados consistia em um portal corporativo criado com o uso do SharePoint Server 2010 e do Serviços do PerformancePoint e que continha um painel de médio porte único. O painel continha dois filtros vinculados a um scorecard, dois gráficos e uma grade. O painel se baseou em uma fonte de dados única do Microsoft SQL Server 2008 Analysis Services (SSAS) que usou os bancos de dados de amostra do AdventureWorks para o cubo do SQL Server 2008 Analysis Services.

A tabela a seguir descreve o tipo e o tamanho de cada elemento no painel.

O painel médio usou o modelo de Cabeçalho e Duas Colunas, e os tamanhos de itens do painel foram definidos como dimensionamento automático ou como uma porcentagem específica do painel. Cada item do painel foi renderizado com uma altura e uma largura aleatórias entre 400 e 500 pixels para simular as diferenças nos tamanhos de janelas de navegadores da Web. É importante alterar a altura e a largura de cada item do painel porque gráficos são renderizados com base nos tamanhos de janelas dos navegadores da Web.

Cenários e processos de teste

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

Uma única combinação de testes foi usada com as seguintes porcentagens de testes iniciados.

As ferramentas de Teste de Carga do Microsoft Visual Studio 2008 foram usadas para criar um conjunto de testes da Web e testes de carga que simularam os usuários alterando filtros aleatoriamente e navegando em grades e gráficos. Os testes usados neste artigo continham uma distribuição normal de pausas de 15 segundos entre interações, também conhecidas como "momentos de reflexão", e um momento de reflexão entre iterações de teste de 15 segundos. A carga foi aplicada para produzir um tempo de resposta médio de dois segundos para renderizar um scorecard ou um relatório. O tempo médio de resposta foi medido durante um período de 15 minutos após um tempo de aquecimento inicial de dez minutos.

Cada nova iteração de teste seleciona uma conta de usuário diferente de um pool de cinco mil contas e um endereço IP aleatório (usando a Troca de IP do Visual Studio) de um pool de aproximadamente 2.200 endereços.

A combinação de testes foi executada duas vezes para o mesmo painel de porte médio. Na primeira execução, a autenticação da fonte de dados foi configurada para usar a Conta de Serviço sem Supervisão, que usa uma conta comum para solicitar os dados. Os resultados de dados são idênticos para vários usuários, e o Serviços do PerformancePoint pode usar um cache para melhorar o desempenho. Na segunda execução, a autenticação da fonte de dados foi configurada para usar a identidade por usuário, e o cubo do SQL Server Analysis Services foi configurado para usar a segurança dinâmica. Nessa configuração, o Serviços do PerformancePoint usa a identidade do usuário para solicitar os dados. Como os resultados de dados podem ser diferentes, nenhum cache pode ser compartilhado entre os usuários. Em alguns casos, o cache para a identidade por usuário pode ser compartilhado quando a segurança dinâmica do Analysis Services não está configurada e as funções do Analysis Services, às quais os usuários e grupos do Microsoft Windows estão atribuídos, são idênticas.

Configuração e topologia de hardware

Hardware de laboratório

Para fornecer um alto nível de detalhes para o resultado do teste, várias configurações de farm foram usadas para teste. As configurações do farm abrangeram de um a três servidores Web, de um a quatro servidores de aplicativos e um único servidor de banco de dados que estava executando o Microsoft SQL Server 2008. Foi feita uma instalação corporativa padrão do SharePoint Server 2010.

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

Depois que o farm foi dimensionado para vários servidores Web, um balanceador de carga de hardware foi usado para balancear a carga de usuários entre vários servidores Web por meio do uso de afinidade do endereço de origem. A afinidade do endereço de origem registra o endereço IP de origem de solicitações recebidas e o host do serviço para o qual elas tiveram a carga balanceada e encaminha todas as futuras transações para o mesmo host.

Topologia

A topologia inicial consistia em dois servidores físicos, com um servidor atuando como servidor Web e de aplicativos e o segundo atuando como servidor de banco de dados. A topologia inicial é considerada uma topologia de dois computadores (2C) ou uma topologia "1 por 0 por 1", em que o número de servidores Web dedicados é listado primeiro, seguido por servidores de aplicativos dedicados e, em seguida, por servidores de banco de dados.

Os servidores Web também são conhecidos como WFE (front-ends da web) mais adiante neste documento. A carga foi aplicada até a identificação de fatores limitadores. Geralmente, a CPU no servidor Web ou no servidor de aplicativos era o fator limitador, e os recursos foram adicionados para solucionar esse limite. Os fatores limitadores e as topologias diferiam significativamente com base na configuração da autenticação da fonte de dados da Conta de Serviço sem Supervisão ou da Identidade por usuário com segurança de cubo dinâmica.

Resultados do teste

Os resultados do teste contêm três medidas importantes para ajudar a definir a capacidade do Serviços do PerformancePoint.

Em topologias maiores do que quatro servidores de aplicativos, é provável que o afunilamento seja o servidor do Analysis Services. Avalie a possibilidade de monitorar a CPU e o tempo de consulta de seu servidor do Analysis Services para determinar se você deve dimensionar o Analysis Services para vários servidores. Qualquer atraso no tempo de consulta no servidor do Analysis Services aumentará significativamente o tempo médio de resposta do Serviços do PerformancePoint para além do limite desejado de dois segundos.

As tabelas a seguir mostram um resumo dos resultados de teste para a autenticação da Conta de Serviço sem Supervisão e para a autenticação por usuário, quando se expande de dois para sete servidores. Os resultados detalhados que incluem contadores de desempenho adicionais são incluídos mais adiante neste documento.

Resumo da autenticação da Conta de Serviço sem Supervisão

Resumo da autenticação por usuário

Topologias 2C e 3C

Para ajudar a explicar o custo de hardware por transação e a curva do tempo de resposta, os testes de carga foram executados com quatro cargas de usuário crescentes até a carga máxima de usuários para as topologias 2C e 3C.

Autenticação da Conta de Serviço sem Supervisão

Autenticação por usuário

Resultados do farm 3C (1x1x1)

Autenticação da Conta de Serviço sem Supervisão

Autenticação por usuário

Resultados para mais de 4C com autenticação da Conta de Serviço sem Supervisão

Começando com a topologia de 4C, a carga foi aplicada para produzir um tempo de resposta médio de dois segundos para renderizar um scorecard ou um relatório. Em seguida, um servidor extra foi adicionado para solucionar o fator limitador (sempre CPU no servidor Web ou no servidor de aplicativos) e, em seguida, a combinação de testes foi executada novamente. Esta lógica foi repetida até alcançar um total de sete servidores.

Resultados para mais de 4C com autenticação por usuário

Os mesmos testes foram repetidos para uma fonte de dados configurada para autenticação por usuário. Observe que adicionar um servidor de aplicativos para criar uma topologia de quatro servidores de aplicativos não aumentou o número de usuários ou solicitações por segundo para o qual havia suporte do Serviços do PerformancePoint por causa dos atrasos de consulta que o Analysis Services produziu.

Recomendações

Recomendações de hardware

Os contadores de memória e processador das tabelas de teste devem ser usados para determinar os requisitos de hardware para uma instalação do Serviços do PerformancePoint. Para servidores Web, o Serviços do PerformancePoint usa os requisitos recomendados de hardware do SharePoint Server 2010. Os requisitos de hardware do servidor de aplicativos talvez precisem ser alterados quando o Serviços do PerformancePoint consome uma grande quantidade de memória. Isso acontece quando as fontes de dados são configuradas para a autenticação por usuário ou quando o servidor de aplicativos executa vários painéis com longos tempos limites da fonte de dados.

O servidor de banco de dados não se tornou um afunilamento nos testes e alcançou o máximo de uso de CPU de 31% no painel 7C autenticado pela Conta de Serviço sem Supervisão. As definições de conteúdo do Serviços do PerformancePoint, como relatórios, scorecards e KPIs, são armazenadas em listas do SharePoint e são armazenadas em cache na memória pelo Serviços do PerformancePoint, reduzindo a carga no servidor de banco de dados.

Consumo de memória

O Serviços do PerformancePoint pode consumir grandes quantidades de memória em algumas configurações, e é importante monitorar o uso de memória do pool de aplicativos do Serviços do PerformancePoint. O Serviços do PerformancePoint armazena em cache vários itens em memória, incluindo o Analysis Services e outros resultados de consulta da fonte de dados para o tempo de vida do cache da fonte de dados (um padrão de dez minutos). Quando você está usando uma fonte de dados configurada para autenticação de Conta de Serviço sem Supervisão, esses resultados de consulta são apenas armazenados uma vez e compartilhados entre vários usuários. No entanto, quando você usa uma fonte de dados configurada para autenticação por usuário e a segurança do cubo dinâmico do Analysis Services, os resultados de consulta são armazenados uma vez por usuário e por exibição (ou seja, uma combinação "por filtro").

A API do cache subjacente que o Serviços do PerformancePoint usa é a API do Cache ASP.NET. A vantagem significativa de usar essa API é que o ASP.NET gerencia o cache e remove itens (o que também é conhecido como corte) com base em limites de memória, para evitar erros de falta de memória. O limite de memória padrão é 60% da memória física. Depois de alcançar esses limites, o Serviços do PerformancePoint ainda renderizou exibições, mas os tempos de resposta aumentaram significativamente durante o curto período em que o ASP.NET removeu as entradas armazenadas em cache.

O contador de desempenho "Aplicativos ASP.NET \ Cortes de API de Cache" do pool de aplicativos de host do Serviços do PerformancePoint pode ser usado para monitorar os cortes de cache do ASP.NET que ocorrem por pressão da memória. Se esse contador for maior do que zero, examine a tabela a seguir para encontrar possíveis soluções.

Uma fonte de dados configurada para usar a autenticação por usuário pode compartilhar resultados de consulta e entradas de cache quando os conjuntos de associação de funções do Analysis Services dos usuários são idênticos e quando a segurança do cubo dinâmico não está configurada. Esse é um novo recurso do Serviços PerformancePoint no Microsoft SharePoint Server 2010. Por exemplo, se o usuário A estiver nas funções 1 e 2, o usuário B estiver nas funções 1 e 2 e o usuário C estiver nas funções 1, 2 e 3, somente o usuário A e o usuário B compartilharão entradas de cache. Se houver segurança de cubo dinâmico, os usuários A, B e C não compartilharão as entradas de cache.

Analysis Services

Quando o Serviços do PerformancePoint estava sendo testado com autenticação por usuário, duas propriedades do Analysis Services foram alteradas para melhorar o desempenho da produtividade para vários usuários. A tabela a seguir mostra as propriedades que foram alteradas e um novo valor de cada propriedade.

Essas duas definições de memória configuram o Analysis Services para usar o heap do Windows em vez do heap do Analysis Services. Antes de alterar essas propriedades e durante a adição de carga de usuário, os tempos de resposta aumentaram significativamente de 0,2 segundos para mais de 30 segundos, enquanto a CPU nos servidores Web, de aplicativos e do Analysis Services permaneceu baixa. Para solucionar o problema, o tempo de consulta foi coletado por meio do uso de DMV (exibições de gerenciamento dinâmico) do Analysis Services, que apresentaram um aumento de tempos de consulta individuais de 10 milissegundos para 5.000 milissegundos. Esses resultados levaram à modificação das configurações de memória acima.

É importante observar que, embora isso tenha melhorado significativamente a produtividade, segundo a equipe do Analysis Services, a alteração dessas configurações tem um custo pequeno, mas mensurável em consultas de um único usuário.

Antes de alterar qualquer propriedade do Analysis Services, consulte o white paper do SQL Server 2008 sobre o guia de desempenho do Analysis Services (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x416) para obter práticas recomendadas sobre como melhorar o desempenho da produtividade para vários usuários.

Afunilamentos comuns e suas causas

Durante o teste de desempenho, vários afunilamentos comuns foram revelados. Um afunilamento é uma condição em que a capacidade de um elemento específico de um farm é alcançada. Isso causa uma estabilização ou uma diminuição na produtividade do farm. Quando a alta utilização do processador é encontrada como um afunilamento, servidores adicionais são adicionados para resolver o afunilamento. A tabela a seguir lista alguns afunilamentos comuns e possíveis soluções, considerando uma baixa utilização do processador e não o afunilamento.

Monitoramento de desempenho

Para ajudar você a determinar quando é necessário aumentar a escala do sistema ou expandi-lo, use contadores de desempenho para monitorar a integridade do sistema. O Serviços do PerformancePoint é um serviço WCF do ASP.NET e pode ser monitorado com o uso dos mesmos contadores de desempenho utilizados para monitorar qualquer outro serviço WCF do ASP.NET. Além disso, use as informações nas tabelas a seguir para determinar contadores de desempenho suplementares a serem monitorados e para qual processo os contadores de desempenho devem ser aplicados.

See Also

Concepts

Planejar os Serviços do PerformancePoint (SharePoint Server 2010)