Estimar a capacidade e o desempenho para o Gerenciamento de Conteúdo da Web (SharePoint Server 2013)
APLICA-SE A:
2013 
2016 2019 Subscription Edition SharePoint no Microsoft 365
Muitas vezes, as empresas utilizam o SharePoint Server 2013 para publicar conteúdos aos quais os utilizadores anónimos acedem num site da Internet ou aos quais os utilizadores autenticados acedem num site da intranet. Este artigo contém dados de capacidade e desempenho para ajudar a planear o número de computadores a utilizar e os tipos de computadores necessários para publicar conteúdos e gerir conteúdos Web no SharePoint Server 2013.
A publicação do SharePoint inclui diferentes tipos de publicações de sites e métodos associados disponíveis para cada site. As funcionalidades de publicação do SharePoint Server 2013 destinam-se a ajudar a criar sites de marca Internet, intranet e extranet. Para obter mais informações sobre a publicação do SharePoint Server 2013, consulte Descrição geral da publicação na Internet, intranet e sites extranet no SharePoint Server.
Introdução
Este artigo aborda os seguintes cenários:
Site de presença na Internet
Fornece informações a clientes, parceiros, investidores e funcionários potenciais. Este tipo de site permite que usuários anônimos da Internet pesquisem informações sobre uma empresa. Geralmente, estes sites possuem identidade visual e a empresa controla rigorosamente o conteúdo.
Site de negócios na Internet
Promove produtos e serviços oferecidos por uma empresa aos clientes. Esses sites podem mostrar um catálogo de produtos que a empresa oferece.
Site de intranet
A empresa publica esse site internamente dentro de uma organização. Esses sites compartilham informações para os usuários autenticados e a empresa gerencia rigorosamente o site para restringir o acesso ou abri-lo para todos os usuários internos.
Site extranet
Fornece acesso ao conteúdo direcionado a funcionários remotos, parceiros e clientes. Esses sites fornecem acesso a uma base de conhecimento que usa conteúdo criado marcado com metadados para categorizar artigos. Os usuários podem pesquisar ou navegar por informações específicas, tais como artigos de solução de problemas e suporte.
A Publicação de Conjunto Entre Sites e a Web Part de Pesquisa de Conteúdo permitem a reutilização dos conjuntos de sites nesses cenários. Esses recursos e funcionalidades afetam a forma como você planeja a capacidade. Para obter mais informações, consulte Visão geral da publicação entre sites no SharePoint Server.
Observação
A Publicação de Conjunto Entre Sites é mencionada como publicação entre sites nesse artigo.
A navegação gerida no SharePoint Server 2013 fornece navegação orientada por taxonomia para um site de publicação. Para saber mais, confira Visão geral da navegação gerenciada no SharePoint Server.
Os dados de desempenho e capacidade deste artigo contém duas partes. A primeira parte é sobre o novo método de publicação entre sites e navegação gerenciada. A segunda parte usa o modelo de criação in-loco.
Observação
Os cenários abordados nesse artigo podem ser obtidos através da publicação entre sites e sites de criação in-loco. Os recursos de navegação gerenciada e publicação entre sites não dependem um do outro e podem ser usados de forma independente.
As duas métricas a seguir são atribuídas nos modelos usados neste artigo:
Taxa de transferência
O número de visualização de página por segundo que o site consegue sustentar
Tempo de resposta do servidor
O tempo que é necessário para o servidor processar uma solicitação, afetando o tempo que leva para o usuário visualizar a página. O tempo de resposta do servidor que fornecemos neste documento é 5º e 95º percentil. Estes valores significam que 95% e 50% das solicitações são mais rápidas do que o valor fornecido, respectivamente. Medimos estes valores com a "Duração" registada na base de dados Utilização do SharePoint para um determinado pedido.
Atualização do conteúdo
O tempo necessário para que o item atualizado reflita nos resultados da pesquisa é uma boa métrica a ser considerada ao trabalhar em cenários de publicação entre sites.
Os cenários deste artigo usam os dois estados a seguir:
Zona Verde
Os servidores estão com 60% de utilização. Este deve ser o destino da maior parte do tempo de funcionamento dos servidores.
Zona Vermelha
Os servidores estão próximos de utilização total. Isto pode ser visto como um estado no qual o site do SharePoint está com mais carga do que o habitual. Na Zona Vermelha, os valores de tempo de resposta do servidor começam a aumentar à medida que o servidor tenta atender a demanda das solicitações de entrada.
Informações de pré-requisito
Antes de ler este artigo, certifique-se de que compreende os principais conceitos subjacentes à gestão de capacidade do SharePoint Server 2013. Os artigos a seguir o ensinam a entender sobre a abordagem recomendada para o gerenciamento da capacidade e fornecem o contexto para ajudá-lo a entender como usar de forma eficaz as informações contidas neste artigo.
Observe que alguns dos novos recursos que afetam a funcionalidade dos cenários de publicação não são abordados neste artigo. Estes cenários incluem canais de dispositivo, otimização de SEO e exibição das regras de consulta e modelos. Além disso, a funcionalidade e configuração do site de publicação entre sites não são descritas em detalhes neste artigo. Para obter mais informações, veja Planear a publicação entre sites no SharePoint Server e Configurar soluções de gestão de conteúdos Web no SharePoint Server.
Para obter mais informações sobre a capacidade e o desempenho para ajudar a compreender os dados neste artigo, consulte Planeamento de desempenho no SharePoint Server 2013.
Publicação entre sites usando navegação gerenciada
Esta seção fornece dados de teste para duas áreas: publicação entre sites com publicação de criação in-loco e de usuários anônimos.
Publicação entre sites com usuários anônimos
Os resultados do teste desta seção são baseados em um modelo de site de publicação entre sites e fornecem uma diretriz de planejamento de capacidade. Ao planejar uma implantação do SharePoint para usuários anônimos acessarem um site, use esta diretriz e ajuste as especificações de implantação de forma correspondente.
Em nossos testes, o caso de teste usa o recurso de publicação de sites. Este cenário fornece diversos conjuntos de sites que são marcados como catálogos e rastreados pelo aplicativo de Serviço de Pesquisa do SharePoint. As Web Parts que usam tecnologia de pesquisa, por exemplo, a Web Part de Pesquisa de Conteúdo e a Web Part de Reutilização de Item de Catálogo exibem o conteúdo das páginas em outro site. Para obter mais informações, consulte Visão geral da publicação entre sites no SharePoint Server.
Usamos as seguintes características no site do modelo, que criamos para testar a publicação entre sites:
Publicação de um site que tenha aproximadamente 5 milhões de páginas ou itens.
Os itens estão associados a cerca de 1.000 categorias.
O conteúdo está localizado em outros conjuntos de site em um ou mais catálogos.
O site usa a navegação gerenciada que está vinculada às categoriais às quais os itens estão associados.
De acordo com a topologia de implantação da base de referência descrita posteriormente nesta lista, o site recebe em média até 80 visualizações de página por segundo. Os períodos de pico chegam a até 100 visualizações de página por segundo. Para aumentar o número da taxa de transferência, adicione mais computadores à topologia. Para diminuir o número da taxa de transferência, remova alguns computadores da topologia.
O rastreamento de Pesquisa é executado com rastreamentos contínuos pelo intervalo de 1 minuto com cinco atualizações por segundo no catálogo.
O site tem os seguintes padrões de tráfego e de página:
A página inicial tem três Web Parts de Pesquisa de Conteúdo e Web Part de Painel de Refinamento (recebe 15% do tráfego).
As páginas de Categoria que têm três Web Parts de Pesquisa de Conteúdo, uma Web Part de Painel de Refinamento de Taxonomia e uma Web Part de Painel de Refinamento recebem 45% do tráfego.
As páginas de Itens de Catálogo que têm uma Web Part de Reutilização de Item de Catálogo e duas Web Parts de Pesquisa de Conteúdo recebem 40% do tráfego.
Cada Web Part de Pesquisa de Conteúdo e Reutilização de Item de Catálogo emite uma consulta síncrona.
As páginas de itens de catálogo não usam o Cache de Resultados de Pesquisa Anônima porque recebem uma pequena quantidade de tráfego.
O farm tem o cache de objeto binário grande (BLOB) ativado nos computadores que são executados como servidores front-end da Web.
A topologia de servidor usada para testar esse cenário está no seguinte diagrama:
Figura 1: Topologia de servidor de laboratório de teste
um computador que aloja o SQL Server com todas as bases de dados que o SharePoint utiliza
um computador que hospeda os aplicativos de serviço do SharePoint, serviço de cache distribuído, processamento de análise de pesquisa e funções de administração de pesquisa
um computador que hospeda o rastreamento de pesquisa e funções do processamento de conteúdos (CPC)
três computadores que hospedam nós de índice de pesquisa com processamento de consultas e serve como servidores da Web de front-end
Observação
Os computadores neste teste são computadores físicos que executam o Windows Server 2008 R2. Veja Planeamento da capacidade de pesquisa e Planeamento de capacidade do SharePoint Server 2013 para obter recomendações sobre como utilizar máquinas virtuais e o Windows Server 2012.
Importante
A configuração da topologia do laboratório de teste está otimizada para cenários de publicação orientados a pesquisa. Essa configuração é diferente dos outros tipos de colaboração de implantações do SharePoint. Por exemplo, nossa configuração usa os servidores da Web de front-end como servidores de índice de pesquisa para obter o melhor desempenho. > Na nossa topologia de laboratório de teste, aprendemos que o computador que aloja o servidor da aplicação foi subutilizado. Consequentemente, colocamos o Serviço de Cache Distribuído neste servidor de aplicativos ao invés de um servidor dedicado. Você talvez decida hospedar o Serviço de Cache Distribuído em um servidor dedicado no seu ambiente. Para um melhor desempenho, não recomendamos hospedar o Serviço de Cache Distribuído em um servidor da Web de front-end que tenha a função de servidor de índice de pesquisa.
Relatórios do laboratório de teste
Nós usamos a topologia da figura 1 para nosso laboratório de teste com computadores físicos e um teste de carga do Visual Studio Team System (VSTS). Para obter mais informações, veja Visual Studio Team System. As especificações técnicas dos computadores de teste estão nas tabelas a seguir.
Observação
Nós não usamos o cache do navegador ou solicitações dependentes, tais como arquivos JavaScript ou imagens em nossos testes VSTS. Dependendo da personalização feita para a publicação do site, a quantidade de solicitações dependentes poderá variar consideravelmente. > As páginas que utilizámos nos nossos testes fizeram quase 50 tipos de pedidos de tempo de carregamento de páginas 1 (PLT1) (cache vazia do browser) e cerca de 3 pedidos para tipos de pedido PLT2 (pedidos subsequentes com resultados da cache do browser). Normalmente, as solicitações atendem o Cache do SharePoint BLOB para esses itens e não alteram significativamente os números do desempenho.
| Componentes do servidor | Servidores executando o SharePoint Server |
|---|---|
| Processadores | Intel Xeon CPUs @2,27GHz (2 processadores, total de 8 núcleos, 16 threads) |
| RAM | 24 GB |
| Sistema operacional | Windows Server 2008 R2 Enterprise SP1, 64 bits |
| Tamanho da unidade do SharePoint | 200 GB de disco interno |
| Armazenamento usado para o Índice de Pesquisa | 78 GB em uma matriz de discos externos (2 x Dell PERC H700 SCSI) |
| Número de adaptadores de rede | 2 |
| Velocidade do adaptador de rede | 1 gigabit |
| Autenticação | Nenhum - Anónimo |
| Versão do software | SharePoint Server 2013 |
| Componentes do servidor | Servidores de banco de dados |
|---|---|
| Processadores | CPUs Xeon Intel de L5520 @2.27GHz (2 processadores, total de 8 núcleos, 16 threads) |
| RAM | 24 GB |
| Sistema operacional | Windows Server 2008 R2 Enterprise SP1, 64 bits |
| Matriz de discos | 2 x Dell H700 SCSI |
| Número de adaptadores de rede | 2 |
| Velocidade do adaptador de rede | 1 gigabit |
| Autenticação | NTLM |
| Versão do software | Microsoft SQL Server 2008 R2 SP1 |
Estes são os resultados de um execução de 10 minutos:
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS (simulando usuários simultâneos) | 60 | 100 |
| Tempo de resposta do servidor 50º percentil*: | 219 ms. | 302 ms. |
| Tempo de resposta do servidor 95º percentil*: | 412 ms. | 635 ms. |
| Visualizações de página por segundo: | 78 | 98 |
Trata-se de um cenário de publicação entre sites que exibe o conteúdo do índice de pesquisa. Pode ser interessante examinar o número de consultas que atendem e hospedam a consulta de pesquisa e o número de consultas que o Cache de Resultados Anônimos atende. Neste modelo, o Cache de Resultados Anônimos atende cerca de 60% das consultas. O Cache de Resultados Anônimos será abordado posteriormente neste artigo.
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Total de consultas por segundo: | 235 | 294 |
| Consultas servidas do Cache de Resultados Anônimos: | 145 | 182 |
| Consultas servidas de Pesquisa: | 90 | 112 |
Os valores da média da CPU e do pico do uso de memória desses computadores durante a execução dos testes são os seguintes:
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Média da CPU (Nós de índice de pesquisa por servidor da Web de front-end) | 59% | 80% |
| Média da CPU (servidor de aplicativos, incluindo Cache Distribuído) | 8% | 9% |
| Média da CPU (Nós de pesquisa CPC) | 5% | 5% |
| Média da CPU (SQL Server) | Não medido | Não medido |
| Pico do uso de memória (Nós de índice de pesquisa por servidor da Web de front-end) | 7,5 GB | 7,5 GB |
| Pico do uso de memória (servidor de aplicativos, incluindo Cache Distribuído) | 10,1 GB | 10 GB |
| Pico do uso de memória (Nós de pesquisa CPC) | 6,5 GB | 6,5 GB |
Observe que o uso da memória poderá ser diferente de alguma forma, já que diversos trabalhos de timer são executados no servidor durante o uso normal. Descobrimos que os nós de índice/servidor Web de front-end estavam usando até 12 GB de memória após uma execução de teste de duas semanas com uma carga sustentada.
Como as Web Parts de Pesquisa exibem o conteúdo das páginas de publicação entre sites
Se uma página de publicação contiver uma Web Part de Pesquisa, tal como uma Web Part de Pesquisa de Conteúdo, o navegador começará a processar a página antes da conclusão da consulta da pesquisa. Isso melhora a latência percebida da página. Após a conclusão da consulta da pesquisa, os resultados completos da consulta serão enviados para o navegador e a conexão com o navegador será finalizada. Os usuários talvez pensem que os resultados da pesquisa são carregados de forma assíncrona. No entanto, as consultas ainda são emitidas do servidor enquanto a página está sendo solicitada.
Observe que há um modo assíncrono separado para a Web Part de Pesquisa de Conteúdo, onde as consultas são emitidas a partir do navegador após o carregamento da página.
Efeito das alterações de carga no seu site de publicação de sites
Nós variamos o número de usuários de VSTS (semelhante ao número de usuários simultâneos que acessam o site) utilizados no teste de carga. O gráfico a seguir mostra que o tempo de resposta do servidor aumenta à medida que a carga aumenta, e há certo aumento incremental no número de páginas servidas por segundo. Recomendamos que o tempo de resposta do servidor seja mantido a 750 ms. para garantir que os usuários tenham uma experiência responsiva com a implantação do SharePoint.
Figura 2: Gráfico mostrando a taxa de transferência e tempo de resposta do servidor com diferentes cargas
Expandindo o site de publicação entre sites
Se a implantação do SharePoint for receber mais ou menos tráfego em comparação ao caso da linha de base descrita anteriormente, talvez você queira alterar o número de computadores que estão sendo executados com a função de índice e servidor da Web de front-end no farm para acomodar o tráfego. O gráfico a seguir mostra os resultados da colocação em escala de um site de publicação entre sites com diferentes padrões de carga e um número variado de computadores usados como servidores da Web de front-end com nós de índice e começando com um computador e terminando com 6.
Figura 3: Escalando sua implantação
Para cada uma dessas configurações, nós ajustamos a carga para que o tempo de resposta do servidor tenha valores semelhantes comparados aos da linha de base na seção anterior.
Tenha em atenção que, à medida que o número de computadores aumenta, a complexidade da topologia começa a ultrapassar os ganhos. Cada computador adicional tem menos débito em comparação com os computadores que já se encontram no ambiente. Estes números são fornecidos para mostrar o padrão para aumentar horizontalmente. O desempenho real será alterado consoante a forma como a implementação do SharePoint é criada.
Diretrizes para planejar seu site
A maioria dos nossos testes de desempenho usou a implantação descrita nas seções anteriores. As diretrizes da lista a seguir são destinadas a ajudá-lo a tomar as decisões de planejamento de capacidade corretas quando as implantações forem diferentes das usadas em nosso laboratório de testes.
Mais itens no índice de pesquisa geralmente significa maior latência. Cada partição do índice pode conter até 10 milhões de itens. Os sites normalmente possuem mais de 10 milhões de itens a serem exibidos. Portanto, eles precisam apenas de uma partição, assim como na topologia descrita anteriormente. Você pode usar mais partições para hospedar mais de 10 milhões de itens ou ter mais, menores e mais rápidas partições de índice. Se planear utilizar várias partições de índice, veja Pesquisa de dimensionamento de sites da Internet no SharePoint Server para dimensionar corretamente a topologia de pesquisa.
Cada controle ou Web Part adicionada a uma página (ou no layout da página), adicionará um pouco de sobrecarga ao tempo de resposta do servidor para a página.
Evite usar mais do que cinco Web Parts de Pesquisa de Conteúdo ou Web Parts de Reutilização de Item de Catálogo em uma página. Ao processar um pedido para uma página, o SharePoint Server 2013 executa até cinco consultas em paralelo e devolve os resultados. Se existirem mais de cinco consultas numa página, o SharePoint Server 2013 executa as cinco primeiras consultas antes de começar a executar o próximo conjunto de cinco consultas. Se as páginas requererem mais do que cinco Web Parts de Pesquisa de Conteúdo ou Web Parts de Reutilização de Item de Catálogo, execute as Web Parts de Pesquisa de Conteúdo adicionais no modo assíncrono ou use as regras de consulta ou blocos de resultados.
As Web Parts de Pesquisa de Conteúdo e Web Parts de Reutilização de Item de Catálogo possuem um modo assíncrono. A consulta associada com a Web Part é executada após o navegador carregar a página. Use este método para consultas lentas de forma que o resto da página seja exibido de forma mais rápida para os usuários. No entanto, recomendamos que você use as consultas síncronas para melhores tempos de carregamento de página.
Uma Web Part de Painel de Refinamento com muitos refinadores aumenta o tempo de processamento de uma consulta. Você pode alterar o número de refinadores para mostrar uma propriedade gerenciada. Para obter mais informações, veja Configurar refinadores e navegação por facetas no SharePoint Server
Se você usar a Web Part de Painel de Refinamento de Taxonomia com uma hierarquia profunda de nós de navegação, o tempo para processar uma consulta aumentará. Nós não recomendamos o uso da Web Part de Painel de Refinamento de Taxonomia em uma página que tenha mais de 200 nós de navegação. Um número maior de nós de navegação poderá atrasar o tempo de resposta do servidor e diminuir a taxa de transferência.
Se você precisa criar uma implantação do SharePoint para alta disponibilidade, você deve adicionar o seguinte:
Um computador adicional que execute os aplicativos de serviço nas funções de cache distribuído no caso de haver um computador indisponível
Computadores adicionais para sustentar a carga se houver um ou mais computadores de servidor da Web de front-end com nós de Índice indisponíveis
Um computador adicional nas funções CPC para garantir que as atualizações reflitam no site quando o computador tiver uma função CPC indisponível
Uma topologia do SQL Server que continua a servir consultas de base de dados se um dos servidores de base de dados não estiver disponível
Atualização de conteúdo e velocidade de rastreamento de pesquisa
Durante nossos testes, também realizamos testes com o processo de atualização do conteúdo de catálogo que estava sendo publicado. Em seguida, observamos a quantidade de tempo decorrido antes de um item atualizado aparecer no site de publicação. Em nossos experimentos, fizemos cinco atualizações por segundo no catálogo e definimos rastreamentos contínuos no catálogo em um intervalo de um minuto. Observamos que o tempo médio para a exibição das alterações no site de publicação foi de cerca de dois minutos. O tempo mínimo foi de pouco menos de um minuto e o tempo máximo foi de três minutos. Não observamos uma mudança significativa nesses números ao aumentarmos o número de computadores que estavam sendo executados com a função CPC.
No caso do rastreamento completo do catálogo, no entanto, o aumento no número de computadores que estão sendo executados com a função CPC, aumenta o número de itens processados por segundo. O gráfico a seguir, mostra a relação dos itens processados por segundo e o número de computadores no farm com a função CPC. Observe que estes dados do teste foram obtidos a partir de uma implantação do SharePoint diferente daquela usada nos testes de linha de base. Os resultados devem ser aplicados às implantações do SharePoint, pois a adição de mais nós CPC resulta em melhores tempos de rastreamento completo.
Figura 4: Efeito dos computadores de processamento de conteúdo (CPC) em um rastreamento completo
Portanto, se você precisar de rastreamentos completos mais rápidos para os catálogos, aumente o número de computadores que usam a função CPC na sua implantação.
Carregar no aplicativo de Serviço de Metadados Gerenciados
Nossos testes mostram que os cenários de publicação que envolvem sites que usam navegação gerenciada não possuem requisitos de CPU ou memória significativa no aplicativo de serviço de Metadados gerenciados. No caso de uma implantação igual a descrita anteriormente, o aplicativo de serviço de Metadados Gerenciados pode ser executado em um computador que esteja executando outros aplicativos de serviços do SharePoint. O recurso de Navegação Gerenciada faz uma conexão com o aplicativo de serviço ao receber a primeira solicitação de um site. As solicitações subsequentes usam os valores do cache dos servidores da Web de front-end. Portanto, não haverá nenhuma carga no aplicativo do serviço de Metadados Gerenciados enquanto os servidores da Web de front-end atenderem às solicitações.
Cache de Resultados de Pesquisa Anônima
O Cache de Resultados de Pesquisa Anônima armazena os resultados de uma pesquisa, os dados de refinamento da consulta e as tabelas com resultados adicionais retornados do Serviço de Cache Distribuído do SharePoint. Todas as entradas de cache dependem dos parâmetros de uma consulta, como a ordem de classificação dos resultados, os refinadores solicitados e quaisquer regras de reordenação dinâmicas. O cache afeta todas as consultas manipuladas pelo aplicativo da Web, incluindo as consultas feitas a partir das Web Parts de Pesquisa e dos clientes CSOM. Para obter mais informações, veja Descrição geral da arquitetura de pesquisa no SharePoint Server e Pesquisa de dimensionamento de sites da Internet no SharePoint Server.
Esse cache não é usado para consultas autenticadas por questões de segurança.
Para melhores resultados, nós recomendamos que você configure o Serviço de Cache Distribuído para ser executado apenas em computadores que executem os aplicativos de serviço do SharePoint. O Serviço de Cache Distribuído não deve ser executado em computadores que estejam em funções do servidor da Web de front-end.
Por padrão, o Cache de Resultados da Pesquisa Anônima atualiza os itens a cada 15 minutos. Pode utilizar o Microsoft PowerShell para configurar a duração da cache na aplicação Web onde a cache está configurada:
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
Se você quiser que os resultados sejam mais atualizados do que o valor padrão, diminua o valor. Observe que isto aumentará o número de consultas que o serviço de Pesquisa terá de servir.
Recomendamos que utilize sempre a cache nas páginas de publicação que recebem tráfego pesado. Alguns exemplos para estes tipos de páginas são a home page do site e as páginas de categoria que utilizam Peças Web de Pesquisa. Não recomendamos a colocação em cache para páginas de itens de catálogo. Uma vez que uma página de item de catálogo individual seria acedida com muito menos frequência do que uma home page, pode não valer a pena armazenar o item na cache.
Ao desativarmos o Cache dos Resultados de Pesquisa Anônima em nosso ambiente de teste com os mesmos padrões de carga, o tempo de resposta do servidor aumentou significativamente e a taxa de transferência do número de visualizações de página diminuiu. Eis um gráfico que mostra esta relação:
Figura 5: Efeito do Cache dos Resultados da Pesquisa Anônima
Por padrão, as Web Parts de Pesquisa de Conteúdo são configuradas para usar o Cache dos Resultados de Pesquisa Anônima. As Web Parts de Reutilização de Item de Catálogo, que são usadas nas páginas de item do catálogo não são configuradas para uso devido aos padrões de acesso esparsos que essas páginas geralmente exibem.
Para configurar o comportamento de colocação em cache de uma Peça Web individual para utilizar (ou não utilizar) a Cache de Resultados da Pesquisa Anónima, defina o valor da sub-propriedade "TryCache" na DataProviderJSON propriedade da Peça Web. Se o valor for "true", a consulta utiliza a cache. Se o valor for "false", a consulta não utiliza a cache para consultas de pesquisa Anónima.
Efeito do cache de saída
A colocação em cache de saída é uma forma eficaz de reduzir a carga no SharePoint Server 2013 em cenários de publicação. Para obter mais detalhes sobre como funciona a Cache de Saída neste artigo, veja Output Caching and Cache Profiles (Perfis de Cache de Saída e Cache).
A implantação do SharePoint pode ajudar o Cache de Saída a reduzir a carga nos bancos de dados de conteúdo do SharePoint e no aplicativo de serviço de pesquisa. A seguir, alguns exemplos:
Você está recebendo muito tráfego em algumas de suas páginas.
Você está recebendo muito tráfego nos bancos de dados de conteúdo do SharePoint,
Os computadores que atendem as consultas de pesquisa estão sendo executados com alta utilização da CPU.
Recomendamos que utilize a Colocação em Cache de Saída para páginas muito populares no seu site, como a home page do site ou páginas de categoria de nível superior e determinadas páginas de itens que recebem grandes quantidades de tráfego.
Importante
Existe um problema conhecido no SharePoint Server 2013 quando as páginas que têm a Colocação em Cache de Saída ativada também contêm Peças Web de Pesquisa de Conteúdo. Para evitar este problema na implementação, instale a atualização do SharePoint Server 2013: 12 de março de 2013.
O gráfico a seguir mostra alguns resultados do nosso ambiente de teste onde foi usado o Cache de Saída na página inicial e nas páginas de categoria que recebem 60% do tráfego do site.
Figura 6: Efeito do cache de saída na página inicial e nas páginas de categoria
Observação
As Web Parts de Pesquisa de Conteúdo possuem uma configuração para serem executadas no modo assíncrono. O Cache de Saída não se aplica à carga das Web Parts de Pesquisa de Conteúdo assíncronas.
Processamento da análise de uso
Para ter informações sobre a análise de utilização prontas a utilizar, o SharePoint Server 2013 processa informações que estão na base de dados de utilização. Na nossa topologia, o Processamento da Análise ocorre no nó que contém o nó da Administração de Pesquisa, no serviço de Cache Distribuído e nos outros serviços do aplicativo. Para obter mais informações, veja Descrição geral do processamento de análise no SharePoint Server
Tomamos algumas medidas de tempo de processamento de análise utilizando o site de publicação entre sites usado nos testes anteriores. Medimos o tempo que o SharePoint Server 2013 demora a processar uma grande quantidade de eventos de clique nas páginas do site. Embora os resultados sejam de um site de publicação entre sites, eles também se aplicam a aqueles que usam o método de publicação de criação in-loco.
Para os nossos testes de processamento de análise, geramos os seguintes eventos simulados todos os dias durante uma semana:
27,5 milhões de eventos de clique espalhados por 3 milhões de itens de lista e 400.000 usuários.
A distribuição Zipf foi usada, por isso alguns itens e usuários possuem muitos eventos e alguns outros menos.
Isto gera um total de 7,5 milhões de eventos por dia, simulando diferentes usuários gerando diferentes padrões de tráfego para o site.
Nós acionamos a execução da análise sete vezes para simular uma semana de tráfego. Nós executamos o trabalho da Análise de Uso todos os dias para os dados acumulados nos últimos seis dias. Então, nós medimos o tempo no sétimo dia. O sétimo dia será o dia que demora mais tempo a processar à medida que os itens da semana completa são processados e o gráfico de relações é atualizado. O tempo de execução e uso do disco usado no Dia 8 será semelhante ao do Dia 1.
O processamento da análise não tem um impacto significativo no computador que está sendo executado e nós continuamos com êxito a atender consultas e a manter o conteúdo atualizado no site orientado por pesquisa.
Os resultados são resumidos na tabela a seguir:
| Agenda de testes | Atualizar gráfico de relacionamento | Tempo de execução (horas) | Total de pico de uso do disco | Uso do disco de pico de análise de uso |
|---|---|---|---|---|
| 1º dia | Não | 02:35 | 2,65 GB | |
| 2º dia | Não | 02:43 | ||
| 3º dia | Não | 03:23 | ||
| 4º dia | Não | 04:39 | ||
| 5º dia | Não | 06:08 | ||
| 6º dia | Não | 07:35 | ||
| Day 7 | Sim | 08:29 | 82,4 GB | 4 GB |
O gráfico a seguir exibe os tempos de execução de dias diferentes:
Figura 7: Horas de tempo de execução por dia
Publicação entre sites com usuários autenticados
A publicação do SharePoint normalmente é usada nos sites intranet. Ao utilizar o SharePoint Server 2013, estes sites também podem ser alimentados pela publicação entre sites. As seções a seguir mostram algumas distinções importantes a serem consideradas ao planejar um site de publicação entre sites que usa usuários autenticados. Além das exceções mencionadas nas seções a seguir, as regras que se aplicam aos sites acessados anonimamente também se aplicam aos sites com acesso de usuários autenticados.
Falta de Cache de Resultados de Pesquisa Anônima
Conforme mencionado anteriormente na seção Cache de Resultados de Pesquisa Anônima, esse cache só tem utilidade para os usuários que estão acessando o site do SharePoint de forma anônima. Comparado aos sites acessados anonimamente que usam o Cache de Resultados de Pesquisa Anônima, a capacidade da taxa de transferência dos sites que são sendo acessados por usuários autenticados será significativamente menor. Normalmente, os sites de intranet raramente recebem cargas tão elevadas como as mencionadas na seção anterior (até 100 visualizações de página por segundo). No entanto, esta é uma distinção importante a ser considerada.
O uso do cache de saída pode facilitar a falta do Cache dos Resultados de Pesquisa Anônima para um grau para esses cenários. Os sites de publicação entre sites que esperam diversas visualizações de página por segundo devem considerar a ativação do cache de saída para os seus sites.
Importante
As Web Parts de Pesquisa de Conteúdo possuem uma configuração, que se ativada, faz com que sejam executadas no modo assíncrono. O cache de saída não se aplica à carga das Web Parts de Pesquisa de Conteúdo assíncronas.
Maior índice de pesquisa
Dependendo do tamanho da empresa que implementa o SharePoint Server 2013, as implementações da intranet para o SharePoint Server 2013 normalmente indexarão um maior número de documentos. Isso significa que a topologia de Pesquisa necessária para resumir esses documentos será diferente se comparada à topologia descrita na seção anterior. Veja Planear a pesquisa no SharePoint Server para dimensionar a sua implementação do SharePoint adequadamente.
Publicação de criação in-loco
Esta secção fornece orientações e resultados que utilizam o SharePoint Server 2013, mas não detalha as diferentes funcionalidades que afetam o planeamento da capacidade. Para obter detalhes nesta área, consulte Gestão de conteúdos Web no SharePoint Server.
Publicação de criação in-loco com usuários anônimos
Em nossos testes, trabalhamos com um site que possui as seguintes características:
Site com até 20.000 páginas de artigos divididos em 20 pastas de 1.000 páginas cada ao longo de 50 sites em um único conjunto de sites.
O site usa uma navegação estruturada.
O site geralmente recebe o mínimo de 50 a 100 visualizações de página por segundo.
Os padrões de tráfego atinge a seguinte combinação de páginas:
20 páginas que contém uma única Web Part de Consulta de Conteúdo que emite consultas no banco de dados do conteúdo de escopos variados (20% do tráfego)
30 páginas que incluem diversas Web Parts de Consulta de Conteúdo que emitem consultas no banco de dados do conteúdo de escopos variados (30% do tráfego)
1.600 artigos com 40 K de texto e duas imagens (recebem 50% do tráfego)
A topologia de servidor recomendada está no diagrama a seguir:
Figura 8: Topologia do teste de publicação de criação in-loco
1 computador hospedando o SQL Server
1 computador hospedando os aplicativos de serviço do SharePoint, assim como o servidor da Web de front-end
Resultados do laboratório de teste
Nós usamos a topologia mostrada no diagrama anterior em nosso teste de laboratório com computadores físicos e um teste de carga do Visual Studio Team System.
A tabela a seguir mostra as especificações técnicas usadas nos computadores que testamos:
| Componentes do servidor | Servidores do SharePoint |
|---|---|
| Processadores | CPUs Xeon Intel de @2.33 GHz (2 processadores, total de 8 núcleos, 8 threads) |
| RAM | 24 GB |
| Sistema operacional | Windows Server 2008 R2 Enterprise, 64 bits |
| Número de adaptadores de rede | 2 |
| Velocidade do adaptador de rede | 1 Gbps |
| Autenticação | Nenhum - Anónimo |
| Tipo de balanceador de carga | Balanceador de carga do software do Windows |
| Versão do software | SharePoint Server 2013 |
| Componentes do servidor | Servidor do banco de dados |
|---|---|
| Processadores | CPUs Xeon Intel MP7130M de @2.79 GHz (2 processadores, total de 8 núcleos, 16 threads ) |
| RAM | 16 GB |
| Sistema operacional | Windows Server 2008 R2 Enterprise, 64 bits |
| Matriz do disco | 2 x Dell PERC 5/E |
| Número de adaptadores de rede | 1 |
| Velocidade do adaptador de rede | 1 gigabit ou Gbps |
| Autenticação | NTLM |
| Versão do software | Microsoft SQL Server 2008 R2 SP1 |
A tabela a seguir mostra os resultados de um execução de 10 minutos:
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS: | 5 | 15 |
| Tempo de resposta do servidor 50º percentil: | 69 ms. | 112 ms. |
| Tempo de resposta do servidor 95º percentil | 92 ms. | 221 ms. |
| Visualizações de página por segundo: | 57 | 93 |
| Média da CPU (servidor de aplicativos e servidor da Web de front-end) | 55 | 97 |
| Média da CPU (SQL Server) | 7 | 9 |
| Pico do uso de memória (servidor de aplicativos e servidor da Web de front-end) | 8,9 GB | 8,9 GB |
Efeito do cache de saída
A colocação em cache de saída é uma forma eficaz de reduzir a carga no SharePoint Server 2013 em cenários de publicação. Para saber mais, veja Planejar armazenamento em cache e desempenho no SharePoint Server.
A tabela a seguir mostra os resultados de uma execução de 10 minutos com o cache de saída habilitado e uma taxa de acertos de 90%:
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS: | 5 | 15 |
| Tempo de resposta do servidor 50º percentil: | 2 ms. | 2 ms. |
| Tempo de resposta do servidor 95º percentil | 74 ms. | 88 ms. |
| Visualizações de página por segundo: | 190 | 418 |
| Média da CPU (servidor de aplicativos e servidor da Web de front-end) | 58 | 85 |
| Média da CPU (SQL Server) | 5 | 7 |
| Pico do uso de memória (servidor de aplicativos e servidor da Web de front-end) | 9,2 GB | 9,4 GB |
Os resultados dos testes mostram que o uso do cache de saída pode aumentar significativamente a taxa de transferência de um site de publicação do SharePoint e também reduzir o tempo de resposta do servidor. Para solicitações atendidas a partir do cache de saída, o tempo de resposta é quase instantâneo.
O gráfico a seguir mostra um resumo dos resultados dos testes:
Figura 9: Efeito do cache de saída com o cache de 90% de taxa de acertos
Efeito da navegação gerenciada
No SharePoint Server 2013, os sites de publicação também podem utilizar a navegação gerida. Para obter detalhes sobre como configurar esta opção, consulte Descrição geral da navegação gerida no SharePoint Server.
Nós executamos o mesmo conjunto de testes no nosso site de teste com navegação gerenciada que foi usado nos testes de navegação estruturada. Nossos testes mostram que não há nenhuma diferença significativa no desempenho ao usar a navegação gerenciada ou a navegação estruturada nos sites.
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS: | 5 | 15 |
| Tempo de resposta do servidor 50º percentil: | 70 ms. | 111 ms. |
| Tempo de resposta do servidor 95º percentil | 95 ms. | 215 ms. |
| Visualizações de página por segundo: | 56 | 94 |
| Média da CPU (servidor de aplicativos e servidor da Web de front-end) | 54 | 97 |
| Média da CPU (SQL Server) | 7 | 9 |
| Pico do uso de memória (servidor de aplicativos e servidor da Web de front-end) | 8 GB | 8 GB |
O gráfico a seguir mostra os diferentes tipos de navegação para o mesmo site:
Figura 10: Navegação gerenciada em vez de Navegação Estruturada
Efeito da inclusão de computadores (fora de escala)
Se descobrir que precisa de mais débito de uma implementação do SharePoint, aumentar horizontalmente (aumentar o número de computadores que alojam o SharePoint Server 2013) é uma opção a considerar. O gráfico a seguir mostra como a taxa de transferência aumenta conforme mais computadores são adicionados ao farm:
Figura 11: Efeito na taxa de transferência ao adicionar servidores da Web de front-end
Nos nossos testes, aumentámos a carga no servidor que executa o SharePoint Server 2013 para cada computador que foi adicionado para que os tempos de resposta do servidor fossem aproximadamente os mesmos (cerca de 11 milissegundos para a zona verde, cerca de 250 milissegundos para a zona vermelha).
Sites de publicação de criação in-loco com usuários autenticados
O recurso de publicação do SharePoint normalmente é usado na intranet, onde os usuários que acessam o site são autenticados. Esta seção mostra os testes em que foram usados usuários autenticados e os seus efeitos.
A tabela seguinte mostra os resultados de teste de sites de publicação no local que autenticaram os utilizadores acedidos através da autenticação baseada em afirmações com NTLM. Tenha em atenção que estes testes utilizam hardware idêntico ao dos testes na secção anterior.
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS: | 5 | 15 |
| Tempo de resposta do servidor 50º percentil: | 76 ms. | 107 ms. |
| Tempo de resposta do servidor 95º percentil | 103 ms. | 194 ms. |
| Visualizações de página por segundo: | 54 | 100 |
| Média da CPU (servidor de aplicativos e servidor da Web de front-end) | 50 | 97 |
| Média da CPU (SQL Server) | 6 | 9 |
| Pico do uso de memória (servidor de aplicativos e servidor da Web de front-end) | 9,5 GB | 9,5 GB |
Os números mostram que não há diferença significativa entre solicitações autenticadas e anônimas de acordo com o tempo de resposta do servidor e taxa de transferência.
O gráfico a seguir mostra os diferentes tipos de solicitações para o mesmo site:
Figura 12: Solicitações anônimas versus solicitações autenticadas
Efeito do Cache de Saída nos cenários autenticados
As solicitações autenticadas do servidor requerem uma viagem de ida e volta ao banco de dados do conteúdo para garantir que a conta que está acessando o conteúdo tem permissão para visualizar o conteúdo. Isso significa que as características do desempenho do cache de saída dos sites autenticados são diferentes se comparadas as dos sites anônimos.
A tabela a seguir mostra os resultados de uma execução de 10 minutos com o cache de saída habilitado e uma taxa de acertos de 90%:
| Recursos do teste | Zona Verde | Zona Vermelha |
|---|---|---|
| Número de usuários do VSTS: | 6 | 18 |
| Tempo de resposta do servidor 50º percentil: | 17 ms. | 29 ms. |
| Tempo de resposta do servidor 95º percentil | 87 ms. | 118 ms. |
| Visualizações de página por segundo: | 114 | 236 |
| Média da CPU (servidor de aplicativos e servidor da Web de front-end) | 50 | 97 |
| Média da CPU (SQL Server) | 7 | 10 |
| Pico do uso de memória (servidor de aplicativos e servidor da Web de front-end) | 9,9 GB | 10 GB |
O gráfico a seguir mostra o resumo desses resultados:
Figura 13: Efeito do cache de saída autenticado
Confira também
Conceitos
Planejar o gerenciamento de conteúdo da Web no SharePoint Server
Configurar soluções de gestão de conteúdos Web no SharePoint Server
Configurar definições de cache para uma aplicação Web no SharePoint Server
Planejar armazenamento em cache e desempenho no SharePoint Server