Estimar os requisitos de desempenho e capacidade do Gerenciamento de conteúdo da Web no SharePoint Server 2010

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo apresenta as diretrizes sobre o gerenciamento de capacidade relevantes para os sites do Microsoft SharePoint Server 2010 com a Infraestrutura de Publicação habilitada. Este documento é específico ao SharePoint Server 2010 e as informações abordadas não se aplicam ao SharePoint Foundation.

Este artigo aborda os seguintes cenários:

• Site de publicação na Internet - um site de presença corporativa.

  Esse tipo de site é publicado na Internet e permite que usuários anônimos da Internet localizem informações sobre uma corporação. Sites como esse contêm uma marca, e o conteúdo é rigorosamente controlado.

• Site de publicação na intranet - site interno de notícias.

  Esse tipo de site é publicado internamente, dentro de uma organização. Seu principal uso é compartilhar informações com usuários autenticados, dentro da organização. As informações do site podem ser gerenciadas com rigor ou, em algumas áreas, elas podem ser menos gerenciadas.

• Wiki corporativo - um repositório de conhecimentos.

  Um wiki corporativo é um site de farm único, que cresce organicamente à medida que os parceiros criam novas páginas e as vinculam a outras páginas, que podem ou não existir. Os wikis corporativos geralmente são publicados no ambiente interno de uma organização. Esse site permite que as pessoas em uma empresa ou organização capturem e compartilhem conhecimentos, usando uma solução integrada e aprimorada pelo ambiente do SharePoint.

Após a leitura deste documento, você compreenderá os seguintes conceitos:

• A principal métrica (taxa de transferência) que você deve maximizar para aceitar diversas operações de leitura.

• Os vários afunilamentos possíveis relevantes a uma implantação de Gerenciamento de Conteúdo da Web do SharePoint Server 2010.

• A importância do cache de saída para a maximização da taxa de transferência.

• O efeito das operações de gravação na experiência de leitura do usuário final.

Neste artigo:

• Informações sobre pré-requisitos

• Detalhes e abordagem do teste

• Implantações de Gerenciamento de Conteúdo da Web

• O que otimizar

• Resultados do teste e recomendações

• Sobre os autores

Informações sobre pré-requisitos

Antes de ler este documento, você deve entender os principais conceitos subjacentes ao gerenciamento de capacidade do SharePoint Server 2010. A seguinte documentação o ajudará a conhecer a abordagem recomendada para o gerenciamento da capacidade e fornecerá contexto que o ajudará a entender como fazer uso eficaz das informações deste documento.

Para obter mais informações conceituais sobre desempenho e capacidade, que podem ser úteis para compreender o contexto dos dados deste artigo, consulte os seguintes documentos:

• Gerenciamento de capacidade e dimensionamento do SharePoint Server 2010

• Estudos técnicos de caso de desempenho e capacidade (SharePoint Server 2010)

Detalhes e abordagem do teste

Em cada teste, as variáveis que podem existir no mundo real foram resumidas para mostrar recomendações específicas. Dessa forma, é muito importante testar e monitorar seu próprio ambiente, para verificar se você o dimensionou corretamente para atender ao volume de solicitações esperado. Para saber mais sobre os conceitos de gerenciamento de capacidade, consulte Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010.

Este artigo aborda o desempenho com os Recursos de Conjunto de Sites, a Infraestrutura de Publicação do SharePoint Server e o Cache de saída. Esses recursos só estão disponíveis quando a Infraestrutura de Publicação do SharePoint Server está habilitada. Por padrão, esse recurso está habilitado nos Portais de Publicação.

Conjunto de dados

Os testes foram conduzidos com o uso de um conjunto de dados que compartilha características comuns às implantações reais de Gerenciamento de Conteúdo da Web. Embora o carregamento fosse constante, diferentes páginas foram solicitadas. A tabela a seguir descreve o conjunto de dados usado para esses testes.

Conjunto de dados

Objeto	Site de publicação
Tamanho dos bancos de dados de conteúdo	2.63 GB
Quantidade de bancos de dados de conteúdo	1
Quantidade de conjuntos de sites	1
Quantidade de aplicativos Web	1
Quantidade de sites	50
Número de páginas	20.000 páginas divididas em 20 pastas com 1.000 páginas cada
Composição das páginas	Páginas de artigos em HTML básico, com referências a duas imagens
Tamanho da página	42 KB descompactada; 12 KB compactada
Imagens	3.000 a 30 KB até 1.3 MB cada

É recomendável configurar o IIS (Serviços de Informações da Internet) para sempre compactar arquivos, em vez da configuração padrão de compactar arquivos dinamicamente. Quando a compactação dinâmica está habilitada, o IIS compacta páginas até que a utilização da CPU exceda um determinado limite e, nesse ponto, o IIS para de compactar páginas até que a utilização fique abaixo do limite. Os testes deste artigo foram realizados com a compactação sempre ativada.

Esse conjunto de dados de teste utilizou apenas os recursos padrão do SharePoint Server 2010, que estão incluídos no produto. Seu site provavelmente incluirá personalizações, além desses recursos básicos. Portanto, é importante testar o desempenho da sua própria solução.

Hardware

O número de servidores Web do farm variou em cada teste, mas todos tinham hardware idêntico. A tabela a seguir descreve o hardware de servidor Web e de servidor de aplicativos que foi usado durante os testes.

Especificações de hardware para servidores de aplicativos e servidores Web

	Servidor Web
Processadores	2 núcleos quádruplos a 2.33 GHz
RAM	8 GB
Sistema operacional	Windows Server 2008, 64 bits
Tamanho da unidade do SharePoint	300 GB
Quantidade de adaptadores de rede	2
Velocidade do adaptador de rede	1 gigabit
Autenticação	Básica do Windows
Tipo de balanceador de carga	Balanceamento de carga do hardware
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Administração Central Email de entrada do Microsoft SharePoint Foundation Aplicativo Web do Microsoft SharePoint Foundation Serviço de Timer do Fluxo de Trabalho do Microsoft SharePoint Foundation

A tabela a seguir descreve o hardware do servidor de banco de dados usado para esses testes.

Especificações de hardware para servidores de banco de dados

	Servidor de banco de dados
Processadores	4 núcleos quádruplos a 3.19 GHz
RAM	16 GB
Sistema operacional	Windows Server 2008, 64 bits
Armazenamento	15 discos de 300 GB a 15.000 RPM
Quantidade de adaptadores de rede	2
Velocidade do adaptador de rede	1 gigabit
Autenticação	NTLM
Versão do software	Microsoft SQL Server 2008

Glossário

Há alguns termos especializados que você encontrará neste documento. Aqui estão alguns dos principais termos e suas definições:

• RPS   Solicitações por segundo. O número de solicitações recebidas por um farm ou servidor em um segundo. Esta é uma medida comum de carga de servidor e farm.

  Observe que as solicitações diferem dos carregamentos de página; cada página contém vários componentes, cada um deles cria uma ou mais solicitações quando a página é carregada. Portanto, um carregamento de página cria várias solicitações. Em geral, as verificações e os eventos de autenticação que usam recursos insignificantes não são contados nas medições RPS.

• Zona Verde   Este é o estado em que o servidor pode manter o seguinte conjunto de critérios:

  • A latência no servidor para pelo menos 75% das solicitações é menor que 1 segundo.

  • Todos os servidores têm uma utilização de CPU menor que 50%.

  • A taxa de falha é menor que 0,01%.

Implantações de Gerenciamento de Conteúdo da Web

Há dois modelos que baseiam a autoria de conteúdo nos sites de publicação do SharePoint, os quais podem afetar a sua escolha de topologia de farm de servidores.

No modelo autor no local, um único conjunto de sites é compartilhado por autores e visitantes. Os autores podem criar e atualizar conteúdo a qualquer momento, o que leva a distribuições variáveis de operações de leitura e gravação durante todo o dia. Esse farm de servidores geralmente passa por incontáveis leituras e uma quantidade moderada de gravações.

O diagrama a seguir mostra como a criação no local funciona de uma perspectiva topológica.

No modelo implantação de conteúdo, vários conjuntos de sites, separada e exclusivamente, oferecem suporte à criação e publicação de conteúdo. O conteúdo é criado e atualizado no ambiente de criação e, em seguida, é implantado no ambiente de publicação de acordo com uma agenda, para ser lido pelos visitantes. O ambiente de publicação atende primeiramente às solicitações de leitura, exceto quando o conteúdo está sendo implantado a partir do ambiente de criação. Diferentemente do modelo autor no local, a carga do servidor gerada pela implantação de conteúdo pode ser ajustada para intervalos agendados.

O diagrama a seguir mostra como a implantação de conteúdo funciona de uma perspectiva topológica.

Esses modelos de criação de conteúdo são mutuamente exclusivos.

Embora os sites de publicação na Internet e os sites de publicação na intranet possam usar o modelo autor no local ou o modelo de implantação de conteúdo, os wikis corporativos funcionam melhor com o modelo autor no local. Um wiki corporativo geralmente apresenta um volume maior de operações de gravação em relação às operações de leitura, porque uma proporção maior de usuários pode editar páginas. As páginas de wiki corporativo diferem das páginas de artigo de publicação e exibem características diferentes de desempenho.

O que otimizar

Esta seção aborda as informações de otimização do ambiente de Gerenciamento de Conteúdo da Web. A otimização do ambiente inclui saber como gerenciar taxas de transferência, afunilamentos e armazenamentos em cache.

Nesta seção:

• Taxa de transferência é a métrica principal

• Afunilamentos e correção

• Ajuda do armazenamento em cache

Taxa de transferência é a métrica principal

Taxa de transferência e tempo de resposta são as métricas mais importantes a serem otimizadas quando você faz o planejamento de capacidade para uma implantação de Gerenciamento de Conteúdo da Web do SharePoint Server 2010. A taxa de transferência é o número de operações que um farm de servidores pode executar por segundo, medida em RPS (solicitações por segundo).

Afunilamentos e correção

Afunilamento é o recurso do sistema que, quando atingido, impede que o farm de servidores atenda a solicitações adicionais. O diagrama a seguir mostra os elementos de um farm de servidores e os recursos que podem se tornar afunilamentos e que devem ser monitorados.

Utilização da CPU do servidor Web

A CPU do servidor Web deve ser o afunilamento de uma topologia bem ajustada, pois é o componente mais facilmente escalonável. O balanceador de carga faz o roteamento de solicitações entre os servidores Web e garante que nenhum servidor seja muito mais utilizado do que seus pares.

Embora outros usuários possam visitar o site após a total utilização da CPU do servidor Web, o tempo de resposta do servidor é maior para esses usuários. Esse comportamento é útil ao gerenciamento de picos no volume de solicitações. Entretanto, uma carga constante que exceda a capacidade de um farm de servidores, com o tempo, resultará em uma lista de pendências de solicitações grande o bastante para ultrapassar o limite de solicitações em espera. Nesse ponto, os servidores Web aceleram as solicitações e respondem com um erro HTTP 503. Na ilustração a seguir, o tempo de resposta do servidor diminui após o limite de solicitações em espera ter sido atingido porque somente erros HTTP são exibidos.

As seguintes alterações são mostradas neste diagrama:

1. O tempo de resposta aumenta à medida que a utilização da CPU do servidor Web se aproxima dos 100%.

2. Depois que o limite de solicitações em espera é atingido, solicitações adicionais são exibidas com erros.

Outros afunilamentos

Se a CPU do servidor Web não apresentar afunilamento, os próximos itens a serem investigados para detecção de afunilamentos são a topologia do farm, a configuração do farm ou o conteúdo das páginas em exibição. Alguns possíveis afunilamentos desses elementos incluem o seguinte:

1. Rede   Em situações de alta taxa de transferência, a rede pode ficar saturada entre o servidor Web e o servidor de banco de dados ou entre o servidor Web e os usuários finais. Para que isso não aconteça, é recomendável que os servidores Web usem adaptadores de rede gigabit com 2 portas.

2. CPU do servidor de banco de dados   Se a CPU do servidor de banco de dados apresentar afunilamento, a adição de servidores Web ao farm de servidores não poderá aumentar a taxa de transferência máxima aceita pelo farm. Um afunilamento na CPU de banco de dados, mas não nas CPUs de servidores Web, pode refletir duas situações:

   1. Configurações inadequadas do cache ou páginas muito lentas, especialmente aquelas não armazenadas no cache de saída. Isso se caracteriza por uma alta utilização da CPU do servidor de banco de dados, mas uma taxa de transferência baixa ou média e uma utilização baixa ou média do servidor Web.

   2. O servidor de banco de dados pode ter atingido a capacidade da taxa de transferência necessária ao farm. Isso se caracteriza por uma alta utilização da CPU do servidor Web e do servidor de banco de dados, em uma condição de alta taxa de transferência.

Ajuda do armazenamento em cache

O SharePoint Server 2010 usa três tipos de cache. O objetivo mais comum desses caches é melhorar a eficiência, reduzindo as chamadas ao banco de dados para obtenção de dados solicitados com frequência. As solicitações subsequentes de uma página podem ser atendidas pelo cache no servidor Web, o que resulta em uma utilização consideravelmente reduzida de recursos nos servidores Web e nos servidores de banco de dados.

Estes são os três tipos de cache:

• Cache de saída   Esse cache armazena o conteúdo de página solicitado na memória do servidor Web. Para obter mais informações sobre o cache de saída, consulte o artigo sobre cache de saída e perfis de cache (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x416).

• Cache de objetos   Esse cache armazena objetos do SharePoint, como metadados de item da Web e de lista, na memória do servidor Web. Para obter mais informações sobre o cache de objetos, consulte o artigo sobre cache de objetos (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x416).

• Cache baseado em disco para BLOBs (objetos binários grandes)   Esse cache armazena arquivos de imagem, áudio e vídeo, e outros arquivos binários grandes, no disco. Para obter mais informações sobre o cache BLOB, consulte o artigo sobre cache baseado em disco para objetos binários grandes (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x416).

Cada um desses caches é importante para sustentar uma taxa de transferência alta. Entretanto, o cache de saída tem o maior efeito e é abordado em detalhes em todo este artigo.

Resultados do teste e recomendações

Esta seção aborda as áreas específicas que foram testadas e inclui recomendações resultantes desses testes.

Nesta seção:

• Efeito da habilitação do cache de saída

• Usuários anônimos e usuários autenticados

• Características de expansão das operações de leitura e gravação

• Advertências do cache de saída

• Efeito do volume de leitura na CPU e no tempo de resposta

• Efeito das operações de gravação na taxa de transferência

• Efeito da implantação de conteúdo

• Efeito do instantâneo de banco de dados durante a exportação da implantação de conteúdo

• Características do conteúdo

Efeito da habilitação do cache de saída

O cache de saída é um recurso valioso para otimizar uma solução do SharePoint Server 2010 para muitas operações de leitura.

Nestes testes, para determinar a RPS máxima, o número de usuários ativos fazendo solicitações no farm foi aumentado até que a utilização da CPU do servidor de banco de dados ou dos servidores Web atingisse 100% e apresentasse afunilamento. O teste foi conduzido em topologias de farm 1x1 (1 servidor Web e 1 servidor de banco de dados), 2x1, 4x1 e 8x1, para demonstrar o efeito da expansão de servidores Web em diferentes taxas de acertos do cache de saída.

Taxa de acertos do cache de saída

A taxa de acertos do cache de saída é uma medida dos acertos do cache de saída em relação aos erros.

• Um acerto ocorre quando o cache recebe uma solicitação de dados de objeto já armazenados no cache.

• Um erro de cache ocorre quando uma solicitação é recebida para dados de objeto não armazenados no cache. A ocorrência de um erro faz com que o cache tente armazenar os dados de objeto solicitados, de modo que as solicitações posteriores por esses dados resultem em um acerto de cache.

Há vários motivos que explicam por que uma solicitação de página pode resultar em um erro de cache.

• Páginas configuradas para não usar o cache de saída.

• Páginas personalizadas; por exemplo, páginas com dados específicos do usuário atual.

• Primeira navegação por chave de variação do cache de saída.

• Primeira navegação após a expiração do conteúdo armazenado em cache.

O diagrama a seguir mostra o efeito do cache de saída na taxa de transferência de pico em farms com um a quatro servidores Web e um servidor de banco de dados.

A tabela a seguir lista os efeitos das taxas de acertos do cache de saída nas topologias de farm com um a quatro servidores Web e um servidor de banco de dados.

Efeitos da taxa de acertos do cache de saída em diferentes topologias de farm

Taxa de acertos do cache de saída	Medida	1x1	2x1	4x1
100%	RPS máxima Utilização da CPU do SQL Server	3.463 0%	7.331 0%	11.032 0%
95%	RPS máxima Utilização da CPU do SQL Server	2.137 5,93%	3.945 12,00%	5.937 21,80%
90%	RPS máxima Utilização da CPU do SQL Server	1.518 7,12%	2.864 14,40%	4.518 28,00%
50%	RPS máxima Utilização da CPU do SQL Server	459 9,86%	913 19,50%	1.596  42,00%
0%	RPS máxima Utilização da CPU do SQL Server	172 9,53%	339 19,00%	638 36,30%

Conclusões e recomendações referentes ao efeito da habilitação do cache de saída

Uma taxa de acertos mais alta do cache de saída produz aumentos significativos da RPS máxima. Por isso, é recomendável habilitar o cache de saída para otimizar a solução de publicação do SharePoint Server 2010. É possível configurar o cache de saída na página Configurações do Cache de Saída do conjunto de sites. Para obter mais informações, consulte o artigo sobre definição da página de configurações do cache de saída de um conjunto de sites (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x416) no site Office.Microsoft.com.

Nos testes em que o cache de saída estava habilitado, a primeira solicitação que armazenou uma página no cache foi excluída, ou seja, uma determinada porcentagem de páginas já havia sido armazenada no cache. Quando um usuário solicita pela primeira vez uma página não armazenada em cache, essa página é adicionada ao cache. Se o cache tiver atingido ou estiver perto de atingir sua capacidade, ele cortará os dados que foram menos solicitados recentemente.

A taxa de acertos do cache de 0% simula o período curto em um ambiente, durante o qual o cache de saída habilitado é preenchido após sua liberação. Por exemplo, isso é observado diariamente em um ambiente do mundo real, quando o pool de aplicativos faz a reciclagem. É importante dimensionar o hardware adequadamente para acomodar uma situação em que haja uma taxa de acertos do cache de 0% para o rápido período entre a reciclagem do pool de aplicativos e a próxima solicitação e armazenamento em cache de páginas. A taxa de acertos do cache de 0% também simula um ambiente em que o cache de saída não está habilitado.

Usuários anônimos e usuários autenticados

O teste anterior pressupõe que todas as solicitações ao site são feitas por leitores anônimos. Entretanto, no seu site, alguns ou todos os usuários talvez sejam autenticados. Exemplos de cenários de leitura autenticados incluem um site de publicação de intranet corporativo e conteúdo destinado somente para membros em um site da Internet.

Com os perfis de cache de saída, é possível especificar que o comportamento do cache de saída para usuários autenticados seja diferente do comportamento para usuários anônimos.

Perfis de cache

Os perfis de cache agregam configurações que podem ser aplicadas a páginas, itens de página, tipos de conteúdo e níveis de escala em uma implantação de site. Um perfil de cache define os seguintes tipos de comportamento de cache:

• Quanto tempo os itens devem ser mantidos no cache.

• A política de filtragem de segurança.

• A expiração das configurações; por exemplo, duração e alterações.

• As variações de conteúdo armazenado em cache; por exemplo, com base em permissões do usuário, direitos do usuário e outras variáveis personalizadas.

Qualquer alteração feita em um perfil de cache afeta imediatamente todo o conteúdo aplicável no site. Você pode definir diferentes perfis de cache para usuários anônimos e para usuários autenticados.

O perfil de cache de saída Internet Pública (Somente Anônimo) foi usado para os usuários anônimos e o perfil Extranet (Site Publicado) foi usado para os usuários autenticados.

O gráfico a seguir mostra os efeitos da taxa de transferência autenticada sobre a utilização da CPU do servidor de banco de dados.

O modelo de autenticação era Autenticação Básica do Windows. Embora não seja recomendável usar essa autenticação para sites da Internet, esse método de autenticação foi selecionado para demonstrar o mínimo de sobrecarga que foi imposta pela autenticação. O tamanho dessa sobrecarga varia de acordo com o seu mecanismo de autenticação específico. Ao testar sua implantação, você deve considerar o efeito do seu mecanismo de autenticação. Para obter mais informações sobre mecanismos de autenticação compatíveis com o SharePoint Server 2010, consulte Planejar métodos de autenticação (SharePoint Server 2010).

Conclusões e recomendações para usuários anônimos e autenticados

Os usuários autenticados experimentam menor RPS e potencial de expansão porque o trabalho adicional de validação de credenciais gera carga no servidor de banco de dados. Como demonstrado nos resultados do teste, a RPS máxima observada quando os usuários são autenticados é consideravelmente menor do que a observada em um farm de acesso anônimo.

Características de expansão das operações de leitura e gravação

Nossos testes foram criados para registrar gravações por hora. Neste artigo, uma gravação é definida como sendo a criação e o check-in de uma nova Página de Publicação ou a edição e o check-in de uma Página de Publicação existente.

Para os testes a seguir, leitores foram adicionados ao sistema até que a utilização da CPU do servidor Web atingisse cerca de 80-90% e, em seguida, as operações de gravação foram executadas no ambiente usando atraso artificial. O total de gravações por hora do teste foi de aproximadamente 500. Usamos uma taxa de acertos do cache de saída de 90% em todos os testes. Executamos o mesmo teste em um farm 1x1, 2x1 e 4x1, e observamos a utilização da CPU do servidor Web e do SQL Server, além da taxa de transferência geral de leitura de cada configuração. Além disso, testamos uma configuração somente leitura anônima como uma linha de base e testamos também uma configuração com leitores autenticados, usando a Autenticação Básica do Windows.

Embora a CPU do servidor Web tenha sido 100% utilizada durante os testes de expansão somente leitura, mantivemos a CPU do servidor Web entre 80-90% para os testes de expansão com gravações. Assim foi feito para deixar espaço para alguma utilização adicional da CPU durante a execução da atividade de gravação.

O gráfico a seguir mostra a RPS geral de leitura observada durante cada teste. A RPS de leitura é expandida linearmente à medida que mais servidores Web são adicionados, inclusive na atividade de gravação. Entretanto, há uma perda de RPS quando as gravações são incorporadas.

A utilização da CPU do servidor de banco de dados cresceu quando o número de servidores Web aumentou. O gráfico a seguir mostra o padrão de crescimento da utilização da CPU do SQL Server nas várias configurações. Conforme observado na seção anterior Usuários anônimos e usuários autenticados deste artigo, a autenticação afeta a utilização da CPU do servidor de banco de dados, e isso fica mais evidente quando a atividade de gravação é adicionada (o que também afeta a utilização da CPU do servidor de banco de dados).

A tendência extrapolada do uso do SQL Server demonstra que o SQL Server apresentará afunilamento com seis servidores Web que tenham solicitações de leitura autenticadas. Entretanto, no caso de leitura anônima, a expansão para um número maior de servidores Web mostra-se funcional.

É importante saber que fatores adicionais em uma implantação usual afetam a carga no servidor de banco de dados, e esses fatores são relevantes e devem ser considerados durante o planejamento da capacidade. Para saber mais sobre como determinar uma zona verde para uma típica utilização da CPU do servidor de banco de dados, consulte Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010.

Conclusões e recomendações para características de expansão das operações de leitura e gravação

Nossos dados mostram que a expansão do número de servidores Web será uma estratégia eficiente para o aumento da taxa de transferência se o servidor de banco de dados não apresentar afunilamento. Em média, o teste misto de leitura anônima e gravações autenticadas gerou um aumento de 52% na utilização da CPU do servidor Web em comparação com um teste misto de leitura anônima e nenhuma gravação. Além disso, as leituras autenticadas agregam uma grande carga adicional ao SQL Server, porque cada solicitação incorre em mais verificações de autenticação, o que exige uma viagem de ida e volta ao SQL Server.

O gráfico a seguir mostra o efeito da taxa de transferência sobre a utilização da CPU do servidor de banco de dados.

Advertências do cache de saída

Se a única preocupação do planejamento de capacidade fosse maximizar a RPS, estes testes recomendariam uma taxa ideal de acertos do cache de 100%. Entretanto, pode não ser viável nem desejável habilitar o cache de saída de algumas ou de todas as páginas por causa dos requisitos de atualização de dados ou das restrições de memória.

Atualização de dados

Os dados apresentados no cache de saída talvez não tenham as atualizações feitas recentemente no conteúdo original. Na fonte da implantação de conteúdo ou (para autores autenticados) em um cenário de autor em produção, pode ser conveniente aos autores ver as alterações mais recentes logo após terem atualizado o conteúdo existente.

Em geral, isso é possibilitado pela definição da propriedade Duração no perfil do cache, que especifica o tempo de persistência de uma página armazenada no cache de saída antes que ela expire. Quando uma página expira, ela é removida do cache e uma solicitação posterior resulta em um erro de cache que atualiza o conteúdo da página.

A propriedade de perfil de cache Verificar Alterações também pode ser definida, determinando que o servidor compare o horário do armazenamento da página no cache com o horário em que o conteúdo foi modificado pela última vez em um conjunto de sites. Uma solicitação de página com carimbos de data/hora não correspondentes causa a invalidação do cache para todas as páginas no conjunto de sites. Como a propriedade Verificar Alterações afeta todas as páginas em um conjunto de sites, é recomendável habilitar essa opção apenas quando houver uma solução de autor no local autenticado que não seja atualizada com frequência e que seja basicamente estática. A combinação dessa opção com uma longa duração permite que todas as páginas sejam atendidas no cache até que uma atualização seja feita no site.

Por padrão, a propriedade Verificar Alterações não está habilitada. Isso significa que o servidor Web exibe dados do cache de saída em resposta a solicitações de uma página que ainda não expirou, independentemente de a página ASPX subjacente e original ter sido ou não modificada.

Nesse teste, realizado em um farm de servidores 1x1, todas as variáveis são as mesmas dos testes apresentados na seção Características de expansão das operações de leitura e gravação, com exceção da propriedade Verificar Alterações. Quando a propriedade Verificar Alterações é ativada, o cache é liberado com mais frequência, resultando em uma taxa menor de acertos do cache de saída.

O gráfico a seguir mostra o efeito da propriedade Verificar Alterações na taxa de transferência.

É recomendável evitar a propriedade Verificar Alterações do perfil de cache de saída, exceto em casos específicos. Um site que usa o modelo autor no local e apresenta alterações pouco frequentes no conteúdo pode se beneficiar dessa configuração para usuários autenticados juntamente com uma longa duração de cache, mas outros tipos de sites provavelmente terão alguma degradação da RPS.

Dependendo das suas necessidades, convém ativar o conteúdo com detecção de hora instantaneamente ou com mais rapidez do que o permitido pelas configurações padrão. Nesse caso, você deve diminuir a duração ou não habilitar o cache de saída.

Conclusões e recomendações para advertências do cache de saída

O cache de saída não resolve todos os problemas relacionados ao gerenciamento da capacidade. Há algumas situações em que o cache de saída é inadequado, e você deve considerá-las ao habilitá-lo e configurar perfis de cache de saída.

Efeito do volume de leitura na CPU e no tempo de resposta

Esse teste foi realizado em um farm 1x1 com acesso anônimo e cache de saída habilitado.

O gráfico a seguir mostra o efeito do volume de leitura na CPU e no tempo de resposta.

Conclusões e recomendações para o efeito do volume de leitura na CPU e no tempo de resposta

Como discutido na seção Afunilamentos e correção, o tempo de resposta do servidor geralmente é constante até o servidor Web receber um volume de solicitações suficiente para usar completamente sua CPU. À medida que a CPU do servidor Web é totalmente utilizada, o tempo de resposta aumenta bastante. Entretanto, o farm de servidores ainda pode lidar com algum volume adicional de solicitações.

Efeito das operações de gravação na taxa de transferência

A taxa de criação para operações de edição foi distribuída de maneira uniforme no decorrer dos testes. Os valores de gravações por hora foram testados até aproximadamente 500, pois a criação ou a edição de mais de 500 páginas por hora está fora do intervalo de operação da maioria das implantações do SharePoint. O teste não cobriu os processos automatizados, como a implantação de conteúdo, que foi abordada na seção Efeito da implantação de conteúdo. Essas operações de criação e edição podem resultar em várias operações do SQL Server. Portanto, é importante saber que as gravações avaliadas nesses testes não estão no nível do SQL Server, mas sim, representam o que um usuário considera como uma operação de gravação. Todos os testes de RPS versus gravações por hora foram realizados em um farm 1x1.

Primeiro, adicionamos operações de leitura ao teste até que a CPU do servidor Web estivesse entre 60 e 80%, para deixar um buffer para picos de tráfego, e mantivemos esse nível médio de utilização no decorrer de todo o teste. Em seguida, introduzimos gravações usando um atraso artificial para controlar o número de operações de gravação. Entretanto, houve picos de crescimento do uso da CPU do servidor Web e do SQL Server durante a execução das gravações. Alguns desses picos de algumas taxas de acertos do cache excederam o limite da operação comum, conforme mostrado no gráfico a seguir, embora a média tenha permanecido dentro do intervalo de operação regular.

Como mostrado no gráfico anterior, há uma pequena redução na taxa de transferência à medida que as gravações são adicionadas ao ambiente. O gráfico demonstra a alteração na taxa de transferência entre um cenário somente leitura e as operações de leitura durante aproximadamente 500 gravações por hora. Dois pontos de dados foram registrados para cada taxa de acertos do cache de saída. Portanto, a relação entre os pontos de dados não é necessariamente linear.

A redução percentual é mais pronunciada nas taxas menores de acertos do cache, conforme mostrado no gráfico a seguir. A RPS geral de leitura continua muito relacionada à taxa de acertos do cache, independentemente das gravações.

O gráfico a seguir demonstra que a utilização da CPU do servidor de banco de dados não aumentou significativamente quando as gravações foram adicionadas ao sistema. Observe que a escala vertical é de 0 a 10% da capacidade da CPU.

Carga adicional do SQL Server foi observada durante as operações de gravação, o que era esperado. Entretanto, o maior aumento foi de 2,06%, o que é irrelevante. A utilização média da CPU do servidor de banco de dados permaneceu menor que 10% em todos os testes. Esse teste foi executado em um farm 1x1. O uso da CPU do servidor de banco de dados aumentará à medida que o número de servidores Web for expandido, tema abordado com mais detalhes em Características de expansão das operações de leitura e gravação.

A utilização da CPU do servidor Web também foi avaliada durante os testes. O gráfico a seguir demonstra que o uso médio da CPU do servidor Web permaneceu na faixa de 60-80% no decorrer de todos os testes, mesmo quando as gravações por hora se aproximaram a 500.

Entretanto, a real utilização da CPU medida atingiu o pico quando as gravações ocorreram, conforme mostrado no gráfico a seguir. Em geral, esses picos de CPU não representam um problema. O objetivo da zona verde é fornecer espaço livre de CPU para absorver alguns picos de carga de CPU. Além disso, à medida que mais servidores Web forem adicionados, o efeito dos picos será distribuído entre esses servidores, para que o efeito na CPU de um único servidor Web seja reduzido. Contudo, é preciso saber que esses picos são esperados em uma implantação real; a atividade de gravação não é distribuída de maneira uniforme, embora ela geralmente ocorra de modo intermitente.

Uma taxa de acertos do cache de 90% é muito baixa para uma implantação típica. A maioria das implantações do SharePoint Server 2010, com inúmeras operações de leitura, tem uma taxa de acertos do cache de saída de 95% ou mais.

Conclusões e recomendações para o efeito das operações de gravação na taxa de transferência

Os dados apresentados indicam que as operações de gravação não terão um grande efeito negativo na taxa geral de transferência do sistema para os leitores. É preciso reconhecer que a atividade de gravação pode causar picos de uso da CPU, e você deve planejar sua configuração típica para esperar esses picos. Uma estratégia de redistribuição desses picos é expandir para vários servidores Web. Isso traz duas vantagens:

• Propaga a carga de gravação para vários servidores Web, o que ameniza os picos gerais.

• Proporciona RPS de leitura maior, especialmente em altas taxas de acertos do cache de saída.

Efeito da implantação de conteúdo

Uma alternativa ao modelo autor no local, que usa um único ambiente para edição e leitura, é dividir o ambiente único em dois ambientes separados — um para criação e outro para produção — e usar a implantação de conteúdo para copiar o conteúdo do ambiente de criação para o ambiente de produção.

Nessa configuração, o ambiente de produção abrange desde pouca atividade de gravação até nenhuma, exceto quando a implantação de conteúdo está importando conteúdo. Para esses testes, foram adicionadas leituras até que a utilização da CPU do servidor Web entrasse na faixa de 70-80%. O trabalho de implantação de conteúdo exportou 10 sites, com 500 páginas cada um, do conjunto de sites de criação como um pacote e importou esse pacote para o conjunto de sites de publicação. O tamanho do pacote implantado era maior do que geralmente se observa em ambientes do mundo real, visando estender suficientemente a duração do trabalho de implantação de conteúdo para ver os resultados do teste. Para obter mais informações sobre as características do conteúdo implantado, consulte a seção Conjunto de dados.

Quando a exportação foi concluída, importamos o conteúdo para um conjunto de sites separado e avaliamos o servidor de aplicativos e a carga do SQL Server, e também a taxa de transferência, enquanto a importação estava em andamento. O teste de importação foi executado para várias taxas de acertos do cache de saída.

A principal observação é que a importação teve apenas um pequeno efeito na RPS global de leitura, conforme mostrado no gráfico a seguir. Também observamos que a importação não teve nenhum efeito significativo na utilização da CPU do servidor Web, conforme mostrado nas tabelas a seguir, independentemente da taxa de acertos do cache. Entretanto, houve um efeito mais perceptível na CPU do SQL Server, mostrado no gráfico a seguir. Isso é esperado, porque o servidor de banco de dados apresenta carga adicional durante a importação de conteúdo. O uso da CPU do SQL Server, porém, ficou abaixo dos 12% em todas as taxas de acertos do cache testadas, mesmo durante a importação.

As tabelas a seguir mostram o efeito da importação da implantação de conteúdo na utilização da CPU do servidor Web e do servidor de banco de dados.

Efeito da importação da implantação de conteúdo na utilização da CPU do servidor Web

Acerto do cache	100%	99%	98%	95%	90%	50%	0%
Linha de base	72,32%	73,26%	71,28%	73,53%	71,79%	68,05%	63,97%
Com importação	70,93%	74,45%	69,56%	74,12%	70,95%	67,93%	63,94%

Efeito da importação da implantação de conteúdo na utilização da CPU do servidor de banco de dados

Acerto do cache	100%	99%	98%	95%	90%	50%	0%
Linha de base	1,19%	1,64%	2,01%	3,00%	3,73%	5,40%	6,82%
Com importação	6,03%	6,82%	6,97%	7,96%	8,52%	10,29%	10,56%

Conclusões e recomendações para o efeito da implantação de conteúdo

Os resultados de nossos testes mostram que a execução de operações de implantação de conteúdo durante as operações comuns do site não implica em uma preocupação relevante quanto ao desempenho. Esses resultados mostram que não é estritamente necessário implantar conteúdo durante períodos de pouco tráfego, visando minimizar o efeito da operação no desempenho geral, e que os tempos de implantação podem ser direcionados principalmente pelas necessidades comerciais, e não pelos requisitos de desempenho.

Efeito do instantâneo de banco de dados durante a exportação da implantação de conteúdo

No SharePoint Server 2010, a implantação de conteúdo pode ser configurada para criar um instantâneo do banco de dados de conteúdo de origem antes da exportação de conteúdo. Isso realmente protege o processo de exportação contra atividades de criação que possam ocorrer durante a exportação. Entretanto, os instantâneos podem afetar o desempenho de gravação do servidor de banco de dados, pois o instantâneo atua como um multiplicador das gravações. Por exemplo, se você tiver dois instantâneos de um banco de dados de origem e gravar nesse banco de dados, o servidor de banco de dados copiará os dados existentes para cada instantâneo e gravará os novos dados no banco de dados de origem. Isso significa que uma única gravação no banco de dados de origem, na verdade, implica três gravações:

Para determinar o efeito de um instantâneo no ambiente de criação, medimos a RPS de gravação, o tempo de resposta e a utilização da CPU dos servidores Web, do servidor de banco de dados e do servidor de aplicativos durante uma operação de exportação com atividade de gravação em andamento. As tabelas a seguir exibem os resultados.

Efeito dos instantâneos de banco de dados durante a implantação de conteúdo

Métrica	4 WPH - Nenhum instantâneo	4 WPH - Com instantâneos
RPS de gravação	0,2	0,16
Tempo de resposta	0,13	0,15
% CPU do servidor Web	0,42%	0,27%
% CPU do servidor de aplicativos	8,67%	8,98%
% CPU do servidor de banco de dados	3,34%	2,41%

Efeito dos instantâneos de banco de dados durante a implantação de conteúdo

Métrica	8 WPH - Nenhum instantâneo	8 WPH - Com instantâneos
RPS de gravação	0,44	0,44
Tempo de resposta	0,13	0,13
% CPU do servidor Web	0,61%	0,73%
% CPU do servidor de aplicativos	14,6%	12%
% CPU do servidor de banco de dados	7,04%	7,86%

Conclusões e recomendações para o efeito do instantâneo de banco de dados durante a exportação da implantação de conteúdo

Os resultados de nossos testes mostram que não há nenhum efeito significativo em qualquer ponto de dados avaliado com instantâneos de banco de dados. Toda a variação registrada estava dentro da margem de erro. Isso confirma que os instantâneos de banco de dados podem ser usados sem grandes considerações quanto ao desempenho.

Características de conteúdo

Os testes foram realizados em um único conjunto de dados criado para responder a um conjunto específico de questões. Seu conjunto de dados será diferente e mudará ao longo do tempo. Esta seção investiga como as características de conteúdo; por exemplo, o número de páginas na biblioteca de páginas e os recursos incluídos nas páginas, podem comunicar decisões referentes ao gerenciamento de capacidade.

Número de páginas

A RPS máxima em muitos tamanhos de biblioteca de páginas foi testada. Esse teste foi realizado em uma topologia 4x4 com cache de saída desabilitado e acesso anônimo. Todas as páginas tinham 42 KB quando descompactadas e 12 KB quando compactadas. A tabela a seguir mostra os resultados do teste.

Efeito da contagem de páginas da biblioteca na RPS

Número de páginas	3	1.000	20.000
RPS máxima	860	801	790

O aumento do número de páginas para 20.000 não apresentou efeito significativo na RPS máxima.

Campos de pesquisa de múltiplos valores

Um campo de pesquisa de múltiplos valores é uma coluna, em uma lista, que faz referência a um ou mais itens em outra lista; por exemplo, colunas que usam metadados corporativos gerenciados. Esses campos geralmente são usados como palavras-chave de pesquisa para uma página e não são necessariamente renderizados. Em alguns casos, como nos wikis corporativos, faz sentido renderizar esses valores de campo no conteúdo de páginas. Por exemplo, páginas podem ser arquivadas em categorias quando são criadas (em um site de notícias, pode haver Notícias do Mundo, Interesses Humanitários e Esportes), e a página mestra pode incluir um espaço reservado que mostra ao usuário em qual categoria a página foi marcada.

Campos de pesquisa de múltiplos valores provocam a busca de mais dados sempre que uma página é solicitada. Por isso, a existência de muitos campos de pesquisa de múltiplos valores em uma página pode afetar o desempenho.

O gráfico a seguir mostra o efeito de campos de pesquisa de múltiplos valores na taxa de transferência.

O gráfico a seguir mostra o efeito de campos de pesquisa de múltiplos valores na utilização de recursos do farm.

A degradação da RPS máxima ocorre à medida que o número de campos de pesquisa de múltiplos valores cresce devido ao efeito na rede, entre o servidor Web e o servidor de banco de dados.

Efeito do relatório de uso

O relatório de uso é um serviço que ajuda os administradores a monitorar as estatísticas referentes ao uso de sites. Para obter mais informações sobre o relatório de uso, consulte Configure usage and health data collection (SharePoint Server 2010).

Testamos o efeito dos trabalhos de timer de relatório de uso sobre a RPS máxima em um farm 1x1. A tabela a seguir descreve os resultados.

Efeito do log de uso sobre o desempenho (em RPS)

	BD de uso ativado	BD de uso desativado	Diferença
Cache de saída ativado	3.459	3.463	4
Cache de saída desativado	629	638	9

Os resultados mostram que a habilitação do log de uso não afeta significativamente a RPS em um cenário somente leitura.

Sobre os autores

Joshua Stickler é gerente de programa do SharePoint Server 2010 na Microsoft.

Tyler Butler é gerente de programa do SharePoint Server 2010 na Microsoft.

Zhi Liu é engenheiro de desenvolvimento de software em teste do SharePoint Server 2010 na Microsoft.

Cheuk Dong é engenheiro de desenvolvimento de software em teste do SharePoint Server 2010 na Microsoft.

Philippe Flamm é engenheiro de desenvolvimento de software em teste do SharePoint Server 2010 na Microsoft.