Performance e Disponibilidade em sites SharePoint (Parte I) 

Tags: Performance, SharePoint, Administração

As práticas descritas em baixo são algumas das práticas que devemos ter sempre em consideração aquando do planeamento e execução de um projecto SharePoint.

 

Estas práticas são apenas uma pequeníssima checklist de café, mas que devemos ter sempre em conta, principalmente por todos aqueles que detêm uma menor experiência em desenvolvimento ASP.NET e SharePoint.

 

Planeamento e Gestão de Web Applications / Site Collections

 

Limitar o número de Site Collections e Content Databases, fazendo para tal um estudo percentual da capacidade esperada sobre a capacidade recomendada para cada content database (tipicamente 100 GB).

 

Se cada Site Collection tiver uma quota de 5 GB então, logicamente, não deverão ser alocadas mais de 20 Site Collections por base de dados.

Nunca esquecer que um elevado número de content databases provocará também o caos em termos de manutenção!

 

Por exemplo, em portais colaborativos com milhões de registos e migrações  deverão ser calculadas percentagens de crescimento desde a sua criação até ao momento da sua migração para uma nova plataforma.

 

Um pequeno número de Site Collections por Content Database não só permite uma maior eficiência de operações como também mitiga riscos de problemas que possam ocorrer nessa base de dados, o que afectaria todos os utilizadores do Portal ao invés de afectar apenas um subset desta população.

 

YSlow

Windows Server 2008 R2

 

Considerar a instalação de ambientes SharePoint sob Windows Server 2K8 R2 devido a inúmeros benefícios de performance, incluindo melhorias da Stack TCP/IP, roteamentos e recuperação. Não esquecer também que a instalação de SharePoint (versão 2007) terá de ser levada a cabo via uma slipstream já com o SP2. No entanto recomendo a slipstream já com o SP2 e Cumulative Update de Dezembro de 2009.

 

64-bit

 

É fundamental considerar a instalação em plataformas  64-bit.

 

Em sistemas x86 ou 32-bit muitas vezes existe um lack de performance que é resultado da indisponibilidade do endereçamento de grandes blocos de memória contínua no servidor.

 

Em sistemas x64 ou 64-bit existe um aperfeiçoamento de processamento paralelo, em sistemas x86 ou 32-bit ficaremos sempre limitados a um máximo de 32 processadores.

 

Existem ainda bastantes diferenças entre estas duas topologias (x64 e x86), existindo em x64 ou 64-bit uma protecção face a buffer overflow e uma arquitectura de BUS mais rápida e fiável, entre outras.

 

Políticas de Caching e Compressão

 

É fundamental considerar e encorajar site output caching, blob caching, object caching e compressão HTTP/IIS  quando for possível. Já agora, para todos aqueles que aplicaram estas políticas de caching e tuning, podemos ainda aplicar medidas de tuning de SQL e ainda verificar a técnica CSS Sprites que vai melhorar bastante o número de requests que teremos em cada página do site. Não esquecer que a componente de design, stylesheets e imagens é fundamental para o ganho de performance em quaisquer sites!

 

Performance Monitor

 

Storage e Arquitectura

 

Estes items são sempre um dos potenciais bottlenecks das nossas aplicações. Considerem sempre que possível Clustering, Log Shipping ou Database Mirroring. Considerem também sempre ambientes virtualizados com excepção de SQL e Index Servers que detêm muitas operações de leitura e escrita no(s) disco(s) (I/O). Tipicamente os Query Servers, se não existir hardware para serem servidores autónomos, poderão sempre ser um role activado nos Web Front-Ends.

 

  • Virtualização dos WFE (Web Front-Ends)

 

  • O papel dos web front-ends numa Farm de Microsoft Office SharePoint Server é responder aos pedidos dos utilizadores, renderizando páginas e conteúdos. Este processo envolve a captação ou loading de conteúdos existentes na(s) base(s) de dados SharePoint e filesystem e posterior apresentação desses mesmos conteúdos, efectuando a cache dos mesmos (se esta estiver devidamente configurada e utilizada) e devolvendo os conteúdos requisitados pelos utilizadores em forma de HTML;

 

  • As minhas recomendações vão no sentido da não instalação de  todos os WFE’s no mesmo host físico. Dividindo estas máquinas virtuais entre dois hosts físicos garante-se a redundância de Hardware e a disponibilidade dos conteúdos em caso de falha;

 

  • Deverá considerar-se a utilização de Hardware Load-Balancing sobre Software de Load-Balancing, mas deverá usar-se sempre uma estratégia de Load-Balancing quando se possui  dois ou mais WFE’s na Farm. Desta forma garante-se adisponibilidade dos conteúdos e ao mesmo tempo a performance aplicacional da própria solução, pois existirá um balanceamento da carga e processamento de pedidos por parte dos utilizadores;

 

  • Virtualização dos WFE/Query Servers

 

  • A minha recomendação vai no sentido da combinação de funções dos WFE’s com a função de Query. Em ambientes virtualizados esta assume-se também como uma boa prática mas depende seriamente do ambiente proposto. Neste caso, a tomada de decisão sobre um ambiente virtualizado possibilita a flexibilidade de combinar estes papéis em máquinas distintas;

 

  • Não Virtualização do Index Server

 

  • O papel do Index Server é manter um index actualizado através do crawling full ou incremental  de conteúdos. Posteriormente a sua função é propagar o index actualizado para todos os query servers;

 

  • Este servidor irá ser um dos servidores com maior consumo de memória tornando-o um dos candidatos óbvios à não-virtualização se o SharePoint consumir toda a memória que o servidor físico possui disponível. Este servidor poderá, no entanto ser virtualizado mas tendo sempre em conta que este facto irá reduzir as vantagens proporcionadas pela virtualização de hosts físicos;

 

  • Se o ambiente for pequeno, se for uma Farm de desenvolvimento ou de staging / qualidade ou se o crawling de conteúdo for executado sobre uma pequena porção de dados é perfeitamente viável utilizar discos virtuais para este Index Server;

 

  • A minha recomendação para ambientes de produção ou que necessitem de um crawling de conteúdos de grande escala e dado que este crawling irá representar um significativo aumento de memória e de actividade I/O dos discos, centra-se na instalação deste servidor como um servidor físico e não virtual;

 

  • Virtualização do(s) Application Server(s)

 

  • A minha recomendação vai no sentido da virtualização deste tipo de servidores pois é um servidor com características semelhantes aos WFE’s e se a performance tender a decrescer poderemos sempre e em qualquer altura (desde que a estrutura assim o permita), adicionar novos application servers à Farm, dividindo a carga de serviços;

 

  • Não Virtualização do(s) Database Servers

 

  • O papel do(s) servidore(s) de base dados é armazenar, manter e retornar dados para os outros servidores da Farm. Este servidor é o que mais irá necessitar de actividade I/O dos discos e poderá ter, normalmente, requisitos de memória e de processador elevados. A minha recomendação para este servidor é torná-lo um servidor físico devido essencialmente à latência downstream que a virtualização pode trazer aos outros servidores UI da Farm, pois vários roundtrips podem ocorrer para a execução de uma simples transacção. Assim sendo, aconselho a não virtualização deste servidor devido essencialmente à enorme carga presente no CPU, Memória e I/O de discos;

 

  • Clustering

 

  • A minha recomendação vai no sentido de tornar o servidor back-end SQL Server clustered pois sempre que um nó deste cluster falhar as suas responsabilidades ou tarefas são automaticamente assumidas pelo outro nó e para utilizador final é transparente, pois os seus pedidos são satisfeitos da mesma forma. Assim sendo, esta é uma estratégia que auxilia na redução do downtime da aplicação (ou até mesmo da Farm). No entanto o clustering de SQL Server representa por si só uma solução para a disponibilidade e performance do servidor. É apenas uma parte da solução;

 

  • Como alternativa a esta solução de clustering podemos evoluir também para uma solução de mirroring ou log shipping de SQL Server;

 

  • Mirroring / Log Shipping

 

  • Este processo representa a automatização de backups de bases de dados e seus transaction logs de um servidor de produção SQL Server e o seu restauro num servidor em stand by. No entanto, a parte essencial desta abordagem é o backup dos transaction logs ser realizado durante o dia, num intervalo a especificar, e o seu restauro ser automático no servidor em stand by. Assim, manteremos dois SQL Servers sincronizados e em caso de falha do servidor de produção apenas se terá de redireccionar os pedidos para o novo servidor que estava em stand by, garantindo a total disponibilidade do sistema;

 

Autenticação

 

A minha recomendação vai para o uso de Kerberos sempre que possível que irá reduzir substancialmente o número de round trips por página em comparação com autenticação NTLM.

 

Networking

 

Considerar o ajuste dos settings de timeout do IIS para a gestão de uploads de grandes ficheiros realizados remotamente, via ligações lentas ou VPN.

 

Windows Debugger

Ferramentas Úteis

 

Fiddler Web Debugger

http://www.fiddler2.com/fiddler2/

 

YSlow para Mozilla Firefox

https://addons.mozilla.org/pt-PT/firefox/addon/5369

 

Firebug para Mozilla Firefox

https://addons.mozilla.org/pt-PT/firefox/addon/1843

 

SharePoint Diagnostics (SPDiag)

http://www.microsoft.com/downloads/details.aspx?familyid=1C222804-51C7-4BB5-AE3D-89C68AD27A78&displaylang=en

 

Performance Monitor

http://technet.microsoft.com/en-us/library/bb490957.aspx

 

Windows Debugger (WinDbg)

http://www.microsoft.com/whdc/Devtools/Debugging/default.mspx

 

DebugView (SysInternals)

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

 

Visual Studio Team System 2008 Test Project (para load e web tests)

 

Alguns Links Úteis

 

Tools for performance and capacity planning (Windows SharePoint Services

http://technet.microsoft.com/en-us/library/cc288064.aspx

 

Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server)

http://technet.microsoft.com/en-us/library/cc261795.aspx

 

Espero ter sido útil,

David Alexandre Rosa

Senior Consultant

Rumos Professional Services

Microsoft SharePoint Server Business Unit 

david.rosa@rumos.pt

http://twitter.com/david_rosa

 

Rumos Professional Services

 
Posted em 23-Feb-10
2 Comentários  |  Trackback Url  |  Link para este post | Bookmark este post com:        
 

Links para este post

Failed to render control: The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator.
Nome:
URL:
Email:
Comentário: