Fatores adicionais de planejamento de desempenho e capacidade (Office SharePoint Server)

  • Artigo

Atualizado em: 2009-04-23

Esta seção descreve fatores adicionais que devem ser considerados no planejamento da implantação.

Fatores do ambiente

Web Parts da Consulta de Conteúdo

Fatores do ambiente

Considerações de rede

Segurança da rede

Autenticação

Desenvolvendo código personalizado

Configuração da rede

A configuração da rede é muito importante para o desempenho da instalação do Office SharePoint Server ou do Windows SharePoint Services. Os componentes de rede comuns que podem afetar o desempenho incluem:

  • Placa de Interface de Rede (NIC)

    • Configurações da NIC   Sempre que possível, você deve usar placas de rede Gigabit. Se você tiver placas auto-alternáveis (100 MB / 1 GB), deverá definir sempre que a substituição use 1 Gigabit.

    • Entrada/Saída   Em cenários onde você espera tráfego intenso, é recomendável que você tenha NICs separadas para lidar com o tráfego de entrada e saída.

  • **Comutadores   **Se você executar a rede através de um comutador, assegure-se de que esteja usando um comutador GB e de que tenha o mesmo número de canais de entrada/saída.

  • **Roteadores   **Verifique se os roteadores estão configurados em uma infraestrutura GB.

  • Controladores de domínio   É possível que a autenticação se torne um afunilamento de desempenho no ambiente do SharePoint se o controlador de domínio receber solicitações mais rápido do que puder respondê-las. Em ambientes que usam autenticação do usuário como NTLM, é recomendável uma proporção de 3 servidores Web por controlador de domínio. Se os testes indicarem que a carga de autenticação em 3 servidores Web por controlador é aceitável, você poderá adicionar um servidor Web a mais por controlador de domínio para um limite com suporte de 4 servidores Web por controlador.

Tenha em mente que a configuração de rede deve ser planejada e testada amplamente antes de mover um sistema para ambiente de produção.

Recomendações da topologia de rede

Planeje as conexões de rede nos farms e entre eles. É recomendável que você use uma rede com baixa latência.

A lista a seguir fornece algumas melhores práticas e recomendações.

  • Todos os servidores no farm devem ter latência e largura de banda de LAN no servidor que executa o SQL Server 2005 (latência de até 1 milissegundo).

  • Não foram feitos testes de uma implantação do Office SharePoint Server 2007 na qual um servidor executando o SQL Server 2005 fosse implantado em uma topologia de rede de longa distância (WAN) remotamente de outros componentes do farm com latência de rede maior que 1 ms. Portanto, a topologia de WAN não é recomendável.

  • Planeje uma rede WAN adequada se estiver pretendendo usar o espelhamento de SQL Server 2005 ou o envio de logs do SQL Server 2005 para manter um site remoto atualizado.

Segurança da rede

Consulte Planejar-se para comunicação segura em um farm de servidores (Office SharePoint Server) para obter mais informações sobre segurança da rede.

Autenticação

O mecanismo de autenticação usado no ambiente possui um efeito incremental no desempenho geral do sistema. Os fatores que contribuem para o desempenho da autenticação incluem:

  • O número e a velocidade de viagens de ida e volta ao provedor de autenticação

  • O provedor de autenticação que processa o desempenho

Os testes da Microsoft indicam que a ordem dos mecanismos de autenticação, do mais rápido para o mais lento, são os seguintes:

  1. Anônima

  2. Kerberos

  3. NTLM

  4. Básica

  5. Formulários

Se você optar por criar um provedor de autenticação para usar com o Office SharePoint Server ou Windows SharePoint Services, deverá seguir as diretrizes de melhores práticas no artigo do MSDN sobre autenticação no ASP.NET (diretrizes de segurança no .NET) (em inglês) (https://go.microsoft.com/fwlink/?linkid=98743\&clcid=0x416) (em inglês).

Desenvolvendo código personalizado

A causa mais comum de baixo desempenho em versões anteriores do SharePoint Server é o desenvolvimento e a implantação de recursos personalizados ineficientes na plataforma do SharePoint. Ao desenvolver recursos personalizados para o SharePoint, há algumas medidas de desempenho que você deve monitorar. Essas são apenas algumas delas:

  • Viagens de ida e volta do SQL Server   Nas páginas principais, não são recomendadas mais de 2-3 viagens de ida e volta do SQL. As viagens excessivas causam o seguinte efeito prejudicial no desempenho:

    • Aumento do tempo de resposta do usuário final devido ao maior tempo de processamento no lado do servidor.

    • Redução da taxa de transferência total do sistema devido à carga adicional no servidor de banco de dados.

  • **Utilização da CPU do SQL server   **Para manter a integridade do sistema MOSS, é importante que a utilização de CPU no(s) servidor(es) de bancos de dados permaneça relativamente baixa. Se a média de utilização de CPU do SQL Server 2005 for mais de 60%, o desempenho será afetado de forma adversa. As etapas que você pode realizar para reduzir a utilização de CPU no SQL incluem:

    • Implementar uma estratégia de cache: isso reduz o número total de chamadas do(s) servidor(es) Web para o servidor de banco de dados.

    • Otimizar o código personalizado para usar métodos de objeto que retornem seus dados desejados da maneira mais eficiente (por ex., introduzir índices em listas etc.).

    • Distribuir os bancos de dados do SQL em vários servidores de bancos de dados físicos.

  • Tamanho do download de página   Mantenha o tamanho mínimo de código. Um aumento relativamente pequeno no tamanho da página pode ter um impacto significativo no desempenho se essa página for acessada por muitas pessoas diariamente, especialmente durante horas de pico.

  • Eficiência do código no lado do cliente   Aproximadamente 50% do tempo de resposta do usuário final consiste no processamento no lado do cliente do código retornado. Se a sua solução personalizada aumentar um desses elementos, você pode esperar um efeito negativo no tempo de resposta do usuário final.

  • **Callbacks de AJAX   **Em partes do AJAX, o número de callbacks, e a carga de cada callback. Por exemplo, cada KPI faz 3 chamadas para retornar o resultado. Certifique-se de testar o desempenho da página ao introduzir vários KPIs ou outro código personalizado em uma página.

Web Part de Consulta de Conteúdo

A Web Part de Consulta de Conteúdo utiliza o mecanismo de consulta de lista cruzada do Windows SharePoint Services para recuperar conteúdo de um conjunto de sites do SharePoint. Se a Web Part estiver configurada para emitir uma consulta que envolva um grande número de listas, o mecanismo de consulta de lista cruzada pode dar origem a uma exceção.

Por padrão, as consultas de lista cruzada possuem um limite de 1000 listas. Isso significa que se você configurar a Web Part de Consulta de Conteúdo com uma consulta que inclua mais de 1000 listas, a consulta de lista cruzada não será concluída e a Web Part não exibirá conteúdo. O motivo dessa limitação é evitar a sobrecarga no SQL Server 2005. Quanto mais listas a consulta de lista cruzada incluir, mais tempo irá demorar para que o servidor de banco de dados retorne o conteúdo solicitado pela consulta. Para números muito grandes de listas, isso pode fazer com que o servidor do banco de dados processe de forma desproporcional as consultas de lista cruzada à custa de outras solicitações.

Se os seus requisitos envolverem a consulta de mais de 1000 listas, você poderá aumentar o limite de listas se a carga do banco de dados que as operações requerem for aceitável. Você pode fazer isso adicionando um atributo MaxListLimit à propriedade ListsOverride da Web Part. Por exemplo, se você quiser aumentar o limite de listas para 2000, defina a propriedade ListsOverride como:

 <Lists ServerTemplate="850" MaxListLimit="2000">

Baixar este manual

Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:

Consulte a lista completa de manuais disponíveis na página de download de conteúdo do Office SharePoint Server 2007.