Otimizando o Office SharePoint Server para ambientes de WAN

Atualizado em: 2009-04-23

Neste artigo:

• Criando topologias para a WAN

• Otimizando o processo de rastreamento de conteúdo

• Aceleradores de WAN e outras ferramentas de terceiros

• Criando páginas para downloads mais rápidos

• Otimizando o cache para ambientes WAN

Este artigo destaca meios específicos para você otimizar sua solução doMicrosoft Office SharePoint Server 2007 par melhor desempenho em ambientes de rede de longa distância (WAN).

Criando topologias para a WAN

Você pode configurar com flexibilidade funções de servidor em um farm do Office SharePoint Server 2007 para otimizar requisitos especí­ficos de disponibilidade ou desempenho. Em um ambiente de rede de longa distância (WAN) , há várias características técnicas de funções do servidor cuja compreensão é importante. Além do planejamento voltado para os seus requisitos gerais de desempenho e disponibilidade, o entendimento dessas caracterí­sticas pode ajudar a otimizar a topologia do seu farm de servidores para ambientes WAN.

Otimizando a topologia para o rastreamento de conteúdo

Por padrão, o Office SharePoint Server 2007 usa todos os servidores Web para rastrear conteúdo no farm de servidores. Quando seu farm de servidores é configurado para usar todos os servidores Web para rastreamento, o servidor de indexação envia solicitações a cada servidor Web do farm.

O rastreamento de conteúdo no farm causa excesso de carga nos servidores Web. Isso pode acarretar picos e sobretensão no tráfego da rede e consome muita memória e CPU. O rastreamento de conteúdo no farm pode causar mais tráfego na rede do que as solicitações do usuário. Esse tráfego da rede pode prejudicar o desempenho de todos os servidores Web no farm de servidores e aumentar o tempo de resposta às solicitações do usuário em sites do SharePoint.

Em ambientes WAN, recomendamos que você configure um servidor Web dedicado para rastrear conteúdo, especialmente se estiver rastreando um farm de servidores com mais de 500 gigabytes (GB) de conteúdo ou rastreando conteúdo na WAN. Para garantir que as solicitações dos usuários não sejam afetadas pelo rastreamento de conteúdo, remova o servidor Web dedicado da rotação de balanceamento de carga da rede. Isso é especialmente importante em ambientes globais nos quais as horas de pico de um farm regional—quando há maior probabilidade de que você agende trabalhos de rastreamento—coincidem com as horas de pico do farm central.

Configurando um servidor Web dedicado para rastrear conteúdo local

Para melhor desempenho quando rastrear conteúdo local no farm, configure o servidor de indexação como servidor Web dedicado para rastreamento se o seu servidor de indexação tiver capacidade de memória para as duas funções.

A figura a seguir ilustra um farm otimizado com um servidor Web dedicado para indexação de conteúdo.

Usando o mesmo servidor como servidor de indexação e Web dedicado, você elimina a necessidade do servidor de indexação para enviar solicitações a outro servidor quando rastrear conteúdo. Consequentemente, aumenta o desempenho do rastreamento e reduz o tráfego geral na rede. Se isso não for possível, você pode usar outro servidor no farm de servidores.

Você pode configurar o indexador para usar o servidor Web dedicado utilizando uma das seguintes estratégias:

• Configurar o Serviço do Office SharePoint Server Search na Administração Central do SharePoint.

• Editar arquivo Hosts diretamente.

Para obter mais informações, consulte os seguintes recursos:

• Configurar um servidor Web de front-end dedicado para rastreamento (Office SharePoint Server 2007).

• Configurar um servidor Web front-end dedicado para rastreamento usando a interface do usuário (Office SharePoint Server 2007)

• Configurar um servidor Web front-end dedicado para rastreamento por meio da edição direta do arquivo Hosts (Office SharePoint Server 2007)

Configurando um servidor Web dedicado para rastreamento de farms remotos

Para melhor desempenho de farms regionais quando rastrear conteúdo que se encontre em um farm regional, configure o servidor de indexação no farm central para que use um servidor Web dedicado no farm regional.

A figura a seguir ilustra dois farms regionais, cada um deles otimizado com um servidor Web dedicado para indexação de conteúdo.

• No farm regional 1, um servidor é dedicado à função de servidor Web. Tanto o farm central como o regional 1 usam esse servidor Web dedicado para rastreamento de conteúdo.

• O farm regional 2 está configurado da mesma forma que o farm central com a função de servidor Web também implantada no servidor de indexação.

Observe que o servidor de indexação no farm central não usa a função de servidor Web no farm central para rastrear conteúdo em um farm remoto. O servidor de indexação entra em contato direto com os servidores Web nos farms remotos.

Na figura anterior, se farms regionais estiverem rastreando conteúdo ao mesmo tempo que o farm central, o desempenho será melhor com a configuração do farm regional 1 dos seguintes modos:

• O desempenho do rastreamento no farm regional 1 é aprimorado porque o servidor Web dedicado está em um servidor separado. Consequentemente, o farm central não está afetando o desempenho do servidor de indexação.

• O tempo de rastreamento na WAN é reduzido. O rastreando leva menos tempo porque o servidor Web dedicado no farm regional está respondendo mais do que estaria se estivesse em um servidor compartilhado com o servidor de indexação.

• O processo de rastreamento do farm central é aprimorado, pois o servidor de indexação no farm central está se comunicando com um servidor Web dedicado.

Se você implementar a configuração da topologia ilustrada pelo farm regional 2, poderá otimizar o desempenho agendando processos de rastreamento nos dois farms, para que não haja sobreposição.

Para usar um servidor Web dedicado em um farm remoto para rastrear conteúdo, você deve editar diretamente o arquivo Hosts. Certifique-se de editar o arquivo Hosts no farm que está rastreando o conteúdo, não no farm remoto.

Em uma solução global em que um farm central esteja rastreando conteúdo em farms regionais, edite o arquivo Hosts para incluir uma entrada para cada aplicativo Web em cada farm regional que você deseje rastrear. Uma entrada no arquivo Hosts inclui o endereço IP do servidor Web dedicado seguido do nome do aplicativo Web. Por exemplo:

• 10.10.10.4 TeamSites

• 10.10.10.4 MySites

• 10.10.10.4 Marketing

• 10.10.10.4 Sales

Para obter mais informações, consulte Configurar um servidor Web front-end dedicado para rastreamento por meio da edição direta do arquivo Hosts (Office SharePoint Server 2007).

Otimizando o desempenho em consultas

O desempenho nas consultas dos usuários é uma consideração importante durante a implantação do Office SharePoint Server 2007 em ambientes WAN. Quando um usuário faz uma consulta, ela é enviada a um servidor Web. Esse servidor se comunica com o servidor de consulta para compilar uma lista de resultados e, em seguida, comunica-se com o computador que executa o Microsoft SQL Server para ampliar a lista de resultados com texto resumido, URLs e filtragem de segurança.

Dada a comunicação servidor-a-servidor exigida para retornar resultados da consulta, você pode configurar a topologia para otimizar o desempenho nas consultas. Pequenas otimizações dentro do farm de servidores podem melhorar o desempenho geral observado entre computadores clientes e servidores na WAN.

A otimização mais importante é usar um servidor Web dedicado para rastreamento de conteúdo, conforme discutido na seção anterior. Isso garante que os servidores Web fiquem disponíveis para solicitações dos usuários e não sobrecarregados com trabalhos de indexação.

A seguir, há várias opções diferentes para implantar a função de consulta, cada uma delas fornecendo um tipo diferente de otimização. Cada opção equilibra de modo diferente o atendimento de solicitações de consulta e a redução do tráfego na rede local entre os servidores do farm. A tabela a seguir resume essas opções de configuração e aponta vantagens e desvantagens de cada uma delas.

Configuração	Compensações
Implantar a função de consulta em todos os servidores Web.	Você pode hospedar a função de consulta nos servidores Web para reduzir a comunicação de ida e volta entre servidores do farm. Como resultado, o desempenho nas consulta é otimizado. No entanto, como duas funções de servidor são hospedadas nos mesmos servidores, o desempenho geral dos servidores Web pode ser afetado se houver um uso intenso desses servidores. Consequentemente, certifique-se de implantar servidores Web suficientes para processar solicitações dos usuários nas horas de pico. Embora essa configuração otimize o desempenho da consulta para os usuários, a desvantagem está no back-end do farm. O servidor de indexação propaga o catálogo de índices para cada servidor de consulta em um farm. Se a função de consulta for implantada em múltiplos servidores Web, esta operação requer maiores recursos de servidor durante a propagação de índices.
Dedicar um ou mais servidores à função de consulta.	A ação de dedicar um ou mais servidores para hospedar a função de consulta otimiza esses servidores para que usem todos os recursos disponíveis para executar a função de forma eficiente. Essa configuração também, normalmente, resulta na implantação de menos servidores de consulta. No entanto, essa configuração requer um número maior de comunicações de ida e volta entre servidores no farm para atender às solicitações de servidores Web e à atualização de índices de conteúdo durante a propagação de índices.
Implantar as funções de consulta e índice no mesmo servidor.	Você pode implantar as funções de consulta e de índice no mesmo servidor. Isso otimiza a comunicação no farm porque a propagação de índices não é necessária. No entanto, essa configuração limita o número de servidores que podem hospedar a função de consulta para apenas um servidor. Isso ocorre porque quando a função de consulta é implantada em um servidor de indexação, esse servidor perde a capacidade de propagar índices de conteúdo para outros servidores do farm.

Além de otimizar um farm único para o desempenho de consultas, há várias opções para otimizar cenários multi-farm:

• Em um cenário de serviços compartilhados entre farms no qual um farm pai esteja fornecendo o serviço de pesquisa a um farm filho, implantar um servidor dedicado de consulta no farm pai habilita o farm pai para tratar consultas de pesquisa de farms filhos sem afetar o desempenho das outras opções do usuário no farm pai. Em um cenário de serviços compartilhados entre farms, o servidor Web no farm filho contata diretamente o servidor de consulta e o servidor de banco de dados no farm pai, em vez de comunicar-se através do servidor Web no farm pai. Observe que serviços compartilhados entre farms nos quais um farm pai esteja fornecendo serviços a um farm filho não recebe suporte em WANs. Entretanto, organizações de grande porte podem incluir um site central com um farm pai que forneça serviços e um farm filho que forneça os sites e o conteúdo. Nesse cenário, o farm pai pode ser configurado para rastrear conteúdo em farms regionais em um ambiente multi-farm geograficamente distribuído sem afetar o desempenho do farm filho no site central que esteja fornecendo sites e conteúdo para usuários no site central.

• Em um ambiente multi-farm geograficamente distribuído em que um farm central esteja rastreando conteúdo em farms regionais, você pode otimizar o rastreamento de conteúdo e de desempenho de consulta configurando servidores das seguintes formas:

  • Implante a função de servidor Web no servidor de indexação em todos as farms. Remova este servidor da rotação de balanceamento de carga da rede e configure o processo de rastreamento do farm pai para usar esse servidor Web dedicado para rastrear conteúdo.

  • Implante o servidor de consulta em todos os servidores Web com balanceamento de carga em cada farm.

Separando geograficamente servidores do farm

A comunicação entre servidores em um farm de servidores requer do usuário conexões de rede robustas para atender às solicitações dos usuários adequadamente e evitar gargalos de desempenho. O requisito padrão de rede é que todos os servidores em um farm de servidores residam no mesmo data center, na mesma LAN. Não há suporte para a separação de servidores do farm nos links de uma WAN.

Além dessa diretriz, há requisitos específicos que habilitam um ou mais servidores Web a residir em uma localidade geográfica diferente do restante dos servidores do farm. Nesse cenário, os servidores Web estão em outro data center, mas são conectados à mesma LAN do computador que executa o SQL Server,

Espera-se que esse cenário de implantação atenda aos requisitos de suporte preliminar quando as seguinte condições forem cumpridas:

• A latência da conexão de rede entre um servidor Web e o servidor de banco de dados é inferior a 1 milissegundo (ms). Para atingir essa latência, o ideal é que o servidor Web esteja localizado a, no máximo, 16 km do servidor de banco de dados. Sob as melhores configurações de rede, pode-se obter latência inferior a 1 ms em distâncias de até 160 km, embora isso seja raro. Se a distância estiver entre 16 e 160 km, consulte seus provedores de rede e de hardware para saber se eles podem fornecer um nível de serviço com latência inferior a 1 ms. Não há suporte para a separação de servidores do farm em distâncias superiores a 160 km. Ao medir a latência entre dois data centers que hospedem servidores do mesmo farm, use a ferramenta Ping para medir a latência de um servidor Web no data center remoto para o servidor de banco de dados no data center primário. Divida por dois o resultado obtido para ida e volta.

• Há largura de banda suficiente disponível no link para o tráfego entre o servidor Web e outros servidores no farm.

• Todas as funções de servidor que contribuem para serviços compartilhados estão localizadas no mesmo datacenter do servidor de banco de dados. Isso inclui funções de índice, consulta e serviços do Excel.

• Todos os computadores de servidor do farm estão no mesmo segmento de rede. Não há alternância de roteadores na camada de dados. (Literalmente, a camada física conecta os servidores.) Os roteadores e switches aumentarão a latência, mesmo que a conexão de rede entre eles seja muito rápida.

• Se o tipo de carga que o servidor Web está atendendo for um subconjunto de solicitações de pesquisa de usuários, espera-se que Office SharePoint Server 2007 tolere alguma latência entre o servidor Web e o servidor de banco de dados. Por outro lado, páginas com muitas Web Parts ou Web Parts personalizadas, comandos Stsadm e rastreamentos de pesquisa provavelmente terão pior desempenho.

• Servidores dentro do farm de servidores não cruzam fusos horários. Todos os computadores dos servidores de um farm de servidores devem ser sincronizados no mesmo fuso horário.

Otimizando o processo de rastreamento de conteúdo

A maneira como você agenda e configura processos de rastreamento pode afetar o desempenho e a confiabilidade. Os processos a seguir podem ser otimizados para aprimorar o rastreamento na WAN:

• Coordenar o rastreamento para fontes de conteúdo.

• Configurar as frequências de rastreamento e coordenar rastreamentos completos e incrementais.

• Configurar o rastreamento.

Coordenar o rastreamento para fontes de conteúdo

Em ambientes globais nos quais um farm central esteja rastreando conteúdo em farms regionais em links de WAN, é importante planejar as fontes de conteúdo, pois elas representam as unidades de conteúdo que podem ser agendadas e gerenciadas.

Você adiciona uma fonte de conteúdo para pesquisa quando precisa:

• Rastrear tipos diferentes de repositórios.

• Rastrear alguns repositórios em cronogramas diferentes de outras pessoas.

• Limitar ou aumentar a quantidade de conteúdo rastreada.

Cada um desses motivos pode ser considerado na otimização do rastreamento de conteúdo na WAN. No mínimo, crie uma fonte de conteúdo diferente para cada farm regional. Isso permite agendar o rastreamento em cada farm regional com base nas horas fora do horário de pico e no agendamento de manutenção.

Além disso, crie diferente fontes de conteúdo para um único farm regional com base nos seguintes critérios:

• Crie fontes de conteúdo separadas para o conteúdo que você deseja rastrear mais frequentemente (como conteúdo de colaboração) ou menos frequentemente (como conteúdo publicado).

• Crie uma fonte de conteúdo separada para conteúdos publicados dentro de um cronograma regular. Por exemplo, se você souber que o conteúdo em um conjunto específico de sites é atualizado apenas às sextas-feiras, pode criar uma fonte de conteúdo separada para sincronizar os agendamentos de rastreamento com as atualizações de conteúdo.

• Crie fontes de conteúdo com base no volume de conteúdo que pode ser rastreado em um link de WAN durante horários de menor movimento de um farm regional. Por exemplo, se sua meta for rastrear um grande repositório uma vez por semana, você pode dividir o repositório em cinco a sete blocos de conteúdo que podem ser rastreados com êxito durante a noite e, em seguida, escalone trabalhos de rastreamento no decorrer de cada semana.

• Crie uma fonte de conteúdo separada para o conteúdo externo aos sites do Office SharePoint Server 2007. No Office SharePoint Server 2007 e no Windows SharePoint Services 3.0, o log de alterações registra objetos alterados, incluindo atualizações de ACLs (Listas de controle de acesso). O log de alterações permite rastrear de forma incremental somente o conteúdo alterado, reduzindo significativamente o tempo exigido para novos rastreamentos de uma fonte de conteúdo. O conteúdo armazenado em fontes externas não pode ser rastreado de forma incremental. Consequentemente o processo de rastreamento para essas fontes de conteúdo deve ser gerenciado separadamente. Para obter mais informações, consulte a página que trata de Log de alterações (em inglês) (https://go.microsoft.com/fwlink/?linkid=106007\&clcid=0x416) (em inglês).

Para obter mais informações sobre o planejamento de rastreamento e de fontes de conteúdo, consulte Planejar o rastreamento de conteúdo (Office SharePoint Server).

Configurando as frequências de rastreamento e coordenando rastreamentos completos e incrementais

Conforme discutido na seção anterior, um motivo importante para a criação de fontes de conteúdo separadas é criar a possibilidade de rastrear conteúdo em diferentes agendamentos. Isso é especialmente importante em ambientes nos quais o conteúdo é rastreado por links de WAN com alta latência. Ao agendar trabalhos de rastreamento para farms regionais, leve em conta os seguintes fatores:

• Tempos de inatividade e períodos de pico de uso agendados no farm regional.

• A frequência com que o conteúdo é alterado ou atualizado.

• Disponibilidade de largura de banda e latência do link de WAN. Não deixe de levar em conta outros processos que usam o link de WAN.

Para cada fonte de conteúdo no Office SharePoint Server 2007 e no Windows SharePoint Services 3.0, você pode especificar um horário para rastreamentos completos e outro para rastreamentos incrementais. Observe que você deve executar um rastreamento completo em uma determinada fonte de conteúdo antes de executar um rastreamento incremental. Se você escolher um rastreamento incremental de um conteúdo ainda não rastreado, o sistema executará um rastreamento completo.

Ao planejar agendamentos de rastreamento em um ambiente WAN, considere as seguintes práticas recomendadas:

• Escalone agendamentos de rastreamento para que o uso dos links de WAN seja distribuído no tempo e esses links não fiquem saturados.

• Agende rastreamentos completos somente quando necessário. Recomendamos que você faça rastreamentos completos menos frequentemente do que os rastreamentos incrementais.

• Agende rastreamentos incrementais para cada origem de conteúdo durante horários nos quais os servidores que hospedam o conteúdo estão disponíveis e quando houver pouca demanda de recursos nesses servidores.

• Algumas alterações administrativas no Office SharePoint Server 2007 e no Windows SharePoint Services 3.0—por exemplo, a aplicação de um service pack ou restauração de um banco de dados — disparam automaticamente um rastreamento completo durante o próximo rastreamento regularmente agendado. Agende alterações administrativas que exijam um rastreamento completo para que ocorram pouco antes do agendamento planejado para rastreamentos completos. Por exemplo, recomendamos que você tente agendar a criação da regra de rastreamento pouco antes do próximo rastreamento completo agendado, para que não seja necessário um um rastreamento adicional. Para obter mais informações sobre alterações administrativas que exigem um rastreamento completo, consulte a página sobre "razões para um rastreamento completo" em Planejar o rastreamento de conteúdo (Office SharePoint Server).

Além dessas práticas recomendadas aplicáveis ao rastreamento de conteúdo em sites regionais individuais, certifique-se de que o agendamento do rastreamento completo de um farm central não sobrecarregue o servidor de indexação. Baseie rastreamentos simultâneos na capacidade do servidor de indexação para rastreá-los. O desempenho do servidor de indexação e dos servidores que hospedam o conteúdo determina a extensão em que os rastreamentos podem ser sobrepostos. Uma estratégia para o agendamento de rastreamento pode ser desenvolvida à medida que você se familiarize com as durações típicas do rastreamento para cada fonte de conteúdo.

Para obter mais informações sobre o planejamento de rastreamento e de fontes de conteúdo, consulte Planejar o rastreamento de conteúdo (Office SharePoint Server).

Configurando o rastreamento

Você pode otimizar várias configurações de rastreamento específicas para ambientes WAN para aumentar a confiabilidade dos trabalhos de rastreamento. As seguintes configurações estão disponíveis:

• Configurações de tempo limite para pesquisa

• Regras de impacto do rastreador

Configurações de tempo limite para pesquisa

Os administradores de farm podem especificar o tempo que desejam que o servidor aguarde durante a conexão com outros serviços e quanto tempo o servidor aguardará a confirmação de uma solicitação de conteúdo. Se você adicionar fontes de conteúdo rastreadas em links de WAN, aumente as configurações de tempo limite como medida proativa com base na latência geral do link. Você pode ajustar as configurações de tempo limite a qualquer momento com base no real desempenho do rastreamento de conteúdo em um link de WAN.

Use o seguinte procedimento para especificar configurações de tempo limite do serviço Office SharePoint Server Search.

Especificar configurações de tempo limite

1. Na Administração Central, na guia Gerenciamento de Aplicativos, na seção Pesquisa, clique em Gerenciar Serviço de Pesquisa.

2. Na página Gerenciar Serviço de Pesquisa, na seção Definições de Pesquisa no Nível de Farm, clique em Definições de pesquisa no nível de farm.

3. Na página Gerenciar Definições de Pesquisa no Nível de Farm, na seção Configurações de Tempo Limite, faça o seguinte:

   • Na caixa Tempo de conexão (em segundos), digite o número de segundos que o servidor deverá esperar ao se conectar a outros serviços.

   • Na caixa Tempo de confirmação da solicitação (em segundos), digite o número de segundos que o servidor deverá esperar para que outro serviço reconheça uma solicitação de conexão ao serviço.

4. Clique em OK.

Regras de impacto do rastreador

As regras de impacto do rastreador fornecem um meio para controlar o número de documentos solicitados e rastreados de uma única vez. As regras de impacto do rastreador habilitam os administradores para gerenciar o impacto dos trabalhos de rastreamento sobre links de WAN.

Para cada regra de impacto do rastreador, você pode especificar uma única URL ou usar caracteres curinga no caminho da URL para incluir um bloco de URLs ao qual a regra se aplique. Pode, em seguida, especificar quantas solicitações simultâneas de páginas são feitas à URL especificada, ou decidir solicitar apenas um documento por vez e aguardar um número de segundos à sua escolha entre as solicitações.

Durante a implantação inicial, defina as regras de impacto do rastreador para usar os links WAN da maneira mais eficiente possível enquando ainda rastreia o conteúdo com a frequência necessária para garantir que o conteúdo rastreado permaneça atualizado. Mais tarde, durante a fase de operações, é possível ajustar regras de impacto do rastreador com base nas suas experiências e nos dados de logs de rastreamento.

Use o seguinte procedimento para adicionar uma regra de impacto do rastreador.

Adicionar uma regra de impacto do rastreador

1. Na Administração Central, na guia Gerenciamento de Aplicativos, na seção Pesquisa, clique em Gerenciar Serviço de Pesquisa.

2. Na página Gerenciar Serviço de Pesquisa, na seção Definições de Pesquisa no Nível de Farm, clique em Regras de impacto do rastreador.

3. Na página Regras de Impacto do Rastreador, clique em Adicionar Regra.

4. Na página Adicionar Regra de Impacto do Rastreador, na seção Site, na caixa Site, digite o nome do site que será associado a esta regra de impacto do rastreador.

   Dica

   Ao digitar a URL, você deve excluir o protocolo. Por exemplo, não inclua http:// ou arquivo://.

5. Na seção Frequência de Solicitações, escolha uma das seguintes opções:

   • Solicite qualquer número de documentos de uma vez, até o limite especificado, e não espere entre solicitações. Se você escolher esta opção, use a lista Solicitações simultâneas para especificar quantos documentos deseja que o rastreador solicite por vez ao rastrear essa URL. Você pode especificar o número máximo de solicitações que o serviço Office SharePoint Services Search pode fazer por vez ao rastrear essa URL.

   • Solicitar um documento por vez e aguardar o tempo especificado entre solicitações. Você pode especificar um atraso (em segundos) entre solicitações, ao rastrear essa URL. Quando essa opção é selecionada, o serviço Office SharePoint Server Search faz uma solicitação por site por vez e, em seguida, aguarda o tempo especificado antes de fazer a solicitação seguinte. Na caixa Tempo de espera (em segundos), digite o tempo de espera, em segundos, entre as solicitações. O tempo mínimo é de um segundo e o máximo, de 1.000 segundos.

6. Clique em OK.

Para obter mais informações sobre regras de impacto do rastreador, consulte os seguintes artigos:

• Gerenciar impacto do rastreador (Office SharePoint Server 2007).

• "Regras de impacto do rastreador" em Estimar os requisitos de desempenho e capacidade dos ambientes de pesquisa.

Aceleradores de WAN e outras ferramentas de terceiros

Esta seção descreve as opções para otimizar ambientes WAN com soluções de terceiros nas seguintes categorias:

• Aceleradores de WAN

• Dispositivos de descarregamento e cache

• Soluções de cliente

• Replicação de dados, sincronização de vários mestres e gerenciamento de configuração

• Capacidade de gerenciamento e geração de relatórios de vários farms

• Replicação em nível de byte ou baseada em hardware

Como cada ambiente é diferente, não recomendamos soluções de parceiros específicos. Além disso, as soluções de parceiros tratam as oportunidades de maneiras diferentes. Consequentemente, cada solução tem diferentes pontos fortes. É importante avaliar cada solução com base nas necessidades específicas do seu ambiente e os pontos fortes relativos da solução do parceiro.

Vários parceiros oferecem soluções para aprimorar ou otimizar soluções do Office SharePoint Server 2007. Para obter uma lista atualizada de parceiros, consulte a página sobre Diretório de soluções do sistema Microsoft Office (em inglês) (https://go.microsoft.com/fwlink/?linkid=108591\&clcid=0x416) (em inglês).

Aceleradores de WAN

As soluções de aceleração de WAN não são novas. Algoritmos de caminho mais curtos e ferramentas de compactação de pacotes são oferecidas há décadas. As maiores inovações dos últimos anos têm como foco a otimização da pilha TCP/IP e SMB (Server Message Block).

A maioria dos aceleradores de WAN funciona em pares, com um dispositivo instalado no data center ao lado dos servidores que executam os Produtos e Tecnologias do SharePoint e outro dispositivo na filial. Os dois dispositivos otimizam o tráfego de WAN usando cache, compactação, diferenciação e métodos proprietários para otimizar os pacotes enviados entre eles. Sejam eles dispositivos internos ou simplesmente equipamentos de rede com atualizações para cache, a estratégia é semelhante. As soluções dos diferentes parceiros enfocam a otimização de diferentes camadas na pilha de rede.

Dois critérios importantes a serem considerados para a escolha de um acelerador de rede incluem:

• Os requisitos de segurança da sua organização. Requisitos como IPSec ou HTTPS influenciarão as opções.

• Os aplicativos usados na sua organização. Se você desejar um dispositivo que também forneça otimização para Microsoft Exchange Server e tráfego de compartilhamento de arquivos, isso também influenciará suas opções.

Alguns exemplos de soluções são: Cisco, Citrix, Packeteer, Riverbed e F5.

Dispositivos de descarregamento e cache

Embora as técnicas de cache no SharePoint possa reduzir o tráfego de back-end desnecessário, os parceiros que fornecem dispositivos de descarregamento e armazenamento em cache podem ajudar a fechar a lacuna, incluindo conexões de WAN, entre o cliente e servidores.

Se você estiver hospedando seu site do SharePoint na Internet e sua meta for otimizar o tráfego de rede e reduzir a quantidade de solicitações nos seus servidores, os dispositivos descarregamento e armazenamento em cache podem ajudar bastante. Vários parceiros enfocam soluções para otimizar o processo de hospedagem de conteúdo exposto na Internet. As estratégias empregadas nesse espaço incluem cache e técnicas proprietárias relacionadas, compactação descarregada com algoritmos variados, preparação e pré-busca, além de várias técnicas para carrinhos de compras. Alguns parceiros fornecem excelentes produtos voltados para conteúdos com segurança e eficiência para tipos específicos de clientes, como quiosques públicos, computadores localizados em "cyber cafés" em todo o mundo, ou outros dispositivos mínimos que não são bem conectados.

Também na área da Internet há parceiros que fornecem técnicas globais de roteamento para cache e otimização de rede, para reduzir a perda de pacotes. Por exemplo, algumas soluções otimizam o tráfego de rede de modo que somente os deltas nas solicitações do cliente sejam enviados ao servidor. Esses tipos de soluções resultam em menos tráfego de WAN e podem também resultar em retornos mais rápidos nos quais o número de comunicações de ida e volta entre o cliente e servidor ou entre outros dispositivos intermediários é reduzido.

Assim como o Microsoft ISA, algumas soluções fornecem autenticação delegada ou descarregada como um gateway para o acesso a informações. Essas soluções adicionam uma outra camada de segurança. Para atender a vários requisitos, procure produtos ou soluções que forneçam um firewall, balanceamento de carga e alguma inteligência para descarregamento e cache. Espere ver ainda maior consolidação desses tipos de recursos no futuro.

Alguns exemplos de soluções são: Cisco, F5, Inktomi, Microsoft ISA Server e Microsoft Internet Application Gateway.

Soluções de cliente

Alguns parceiros enfocam a otimização da experiência do cliente, em vez de se voltarem para a infraestrutura de rede e dos servidores. Técnicas como a pré-busca, sincronização em segundo plano, compactação, bloqueadores de anúncios e filtros de imagem podem aumentar drasticamente o desempenho da recuperação de conteúdo na Internet. Isso é especialmente verdadeiro se o texto for a meta principal e se você puder fazer o gerenciamento sem imagens.

Há vários aplicativos clientes que permitem aos usuários sincronizar com sites do SharePoint automaticamente. Após o cliente sincronizar inicialmente com um site, o aplicativo cliente faz automaticamente o cache do conteúdo do site no computador cliente em segundo plano ou quando o cliente está online. Por exemplo, quando um usuário clica em um documento, o documento já está disponível em modo local e o usuário não é afetado por links de WAN. Da mesma forma, quando um usuário adiciona ou atualiza um documento, o aplicativo cliente se encarrega de sincronizar as alterações com o site online. Esses aplicativos clientes geralmente gerenciam quaisquer conflitos que ocorram e permitem que os usuários decidam como resolver conflitos.

Alguns clientes lidam com essa experiência melhor que outros. Alguns fornecem suporte para arquivos somente. Alguns aplicativos fornecem suporte para listas e arquivos. Você provavelmente não localizará Wikis offline, mas poderá localizar leitores RSS para consumir a maioria das listas em modo local ou offline. O Office Outlook 2007 é um exemplo de cliente que permite consumir blogs ou listas do SharePoint offline usando o RSS com leitor RSS, além de sincronizar com bibliotecas de documentos. O Office Groove 2007 também oferece uma boa experiência offline e adiciona os recursos de colaboração ponto a ponto e compactação de arquivos em uma WAN. Para obter mais informações sobre soluções de clientes Microsoft, consulte Estendendo as soluções globais do Office SharePoint Server com os softwares Office Outlook 2007 e Office Groove.

Os parceiros desse espaço concentraram-se em otimizar a experiência do usuário nos casos em que os links de WAN afetam o desempenho ou que os clientes estão frequentemente offline. Os recursos de armazenamento em cache (cópias locais), compactação e passagem da sincronização para o segundo plano podem fazer com que pareça que você está na LAN com o servidor. Se você decidir oferecer aplicativos clientes aos seus usuários, não deixe de fornecer treinamento adequado para que os usuários possam trabalhar com a maior eficiência possível.

Parceiros: Colligo. Microsoft: Microsoft Office Outlook 2007, Office Groove 2007

Replicação de dados, sincronização de vários mestres e gerenciamento de configuração

Seja devido a links de WAN lentos entre dois escritórios ou a requisitos de recuperação de desastres com requisito de vários mestres, a replicação geralmente é necessária em planos de desenvolvimento. O SQL Server 2005 oferece recursos de envio de logs e espelhamento de banco de dados para recuperação de desastres ou failover de sites. No entanto, quando você precisar de dois farms de servidores separados que forneçam acesso de leitura/gravação, há parceiros que oferecem soluções.

Algumas soluções de parceiros incluem um cache de servidor semelhante a um acelerador de WAN. As soluções continuam a fornecer conteúdo do cache em um site remoto, se um link de WAN falhar. Outros parceiros oferecem ótimos produtos para a sincronização de dados quando os sites são conectados depois de longos períodos de desconexão. Por exemplo, um navio que chegue a um porto após um período no mar pode sincronizar com um site central.

Alguns parceiros estendem a interface dos Produtos e Tecnologias do SharePoint para configurar a replicação para pares de aplicativos Web, conjuntos de sites ou listas.

Algumas soluções de parceiros são: Syntergy, WinApp Technologies, Casahl e Infonic.

Capacidade de gerenciamento e geração de relatórios de vários farms

Em implantações globais que incluem múltiplos farms de servidores, o gerenciamento de configurações nos farms e sites pode ser um desafio. Há vários parceiros que oferecem ferramentas desenvolvidas para agilizar o gerenciamento de configurações, permissões, direitos efetivos do usuário e elementos de conteúdo, como páginas mestras e tipos de conteúdo. Se você optar por implantar múltiplos farms de servidores em seu ambiente, considere ferramentas de parceiros que podem ajudar a gerenciar múltiplos farms e grandes volumes de sites.

Alguns parceiros concentram-se em ajudar a definir as configurações de farms e múltiplos ambientes. O Sharepoint Cross Site Configurator (em inglês) (https://go.microsoft.com/fwlink/?linkid=108592\&clcid=0x416) (em inglês) é um exemplo de ferramenta desenvolvida pela Microsoft para configurar auditoria, expiração, páginas mestras e tipos de conteúdo para que seja mantida a consistência em aplicativos Web.

Algumas soluções de parceiros são: Quest Software, echoTechnologies, IDevFactory, AvePoint , CorasWorks, Barracuda Tools, CommVault e Symantec.

Replicação em nível de byte ou baseada em hardware

Os parceiros que fornecem replicação com base em hardware ou em nível de bytes facilitam muito a execução de failover e sincronização de ambientes entre data centers. Se você implementar um disco compartilhado como, por exemplo, uma SAN (rede de área de armazenamento), o disco compartilhado pode se tornar um ponto de falha. Os fornecedores de hardware usam vários métodos para fornecer canais redundantes, fibra redundante, discos redundantes e várias configurações da matriz. Diferentes soluções fornecem níveis variáveis de tolerância a falhas.

Se você quiser eliminar hardware como a fonte potencial de falha, avalie o MSCS (Microsoft Cluster Services). O MSCS oferece tolerância a falhas com base em hardware. Soluções de failover com base em software, como o envio de log SQL e o espelhamento SQL fornecem tolerância a falhas de hardware, mas o failover não é automático quando usado com Produtos e Tecnologias do SharePoint.

Em alguns casos, implementar uma solução que forneça replicação em um nível inferior na pilha pode atender a necessidades específicas do negócio. A replicação no nível de byte, que cria um clone ou espelho do ambiente primário, também pode criar um ambiente secundário para a execução do failover. A replicação contínua no nível de byte pode fornecer um meio para failover automático ou manual.

Um cuidado importante ao avaliar esses tipos de soluções de replicação é entender que nomes de servidores, nomes de aplicativos Web e contas são codificados no banco de dados de configuração. Isso significa que qualquer serviço replicado em outro servidor com outro nome não funciona. Se o nome do servidor permanecer o mesmo nos ambientes replicado e primário, esses tipos de soluções podem funcionar. Independentemente da solução, se uma ferramenta fornecer replicação fora do conhecimento do aplicativo, ela deve ser testada para garantir que funcione em um ambiente de failover.

Algumas soluções de parceiros são: Neverfail e Double-take.

Algumas soluções compiladas para o hardware, como replicação com base em SAN, são: HP, EMC Centera e Hitachi Data Systems.

Criando páginas para downloads mais rápidos

Em um ambiente com capacidade limitada de rede, otimize suas páginas, fazendo com que tenham o menor tamanho e a maior capacidade de resposta possíveis. Há diferentes técnicas para isso, a maioria das quais não é específica dos Produtos e Tecnologias do SharePoint. Os métodos gerais podem ser usados em qualquer site e não serão detalhadamente discutidos nesta seção. Em vez disso, enfocaremos aqui o entendimento dos recursos incluídos nos Produtos e Tecnologias do SharePoint, o que está incluído na página e maneiras como você pode acelerar a visita inicial a um site do SharePoint.

Elementos de página

Uma página em um site do SharePoint consiste em vários elementos exclusivos, como mostra a figura a seguir.

Quando a página é processada, reúne a página mestra, a página de layout e o conteúdo da página.O conteúdo da página inclui os valores para cada campo da página, mas também diversos outros elementos como, por exemplo, tema, folhas de estilo, imagens e navegação. A tabela a seguir mostra um exemplo dos arquivos e fluxos presentes em uma única página de um site do SharePoint. Esse exemplo é uma captura de todas as solicitações de HTTP feitas em uma visita inicial à home page padrão de de um site de portal de colaboração.

URL	Tamanho (bytes)
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

Observe que:

• Foi exigido um total de 29 solicitações para baixar a página.

• O tamanho total da página era de 235 kilobytes (KB).

• Isso representa a carga inicial da página; quase todos os itens da solicitação têm uma diretiva de armazenamento em cache que instrui o navegador para que não as carregue novamente durante um ano. As cargas da segunda página e das páginas subsequentes geram somente três solicitações. Dessas, duas integram a negociação de NTLM que ocorre, logo, somente um item é, na verdade, baixado — o HTML para a página.

• Foi usada a Compactação do IIS de nível 0 padrão, que é o menor volume de compactação possível. Uma compactação adicional resultaria em tamanhos de download ainda menores.

• Dos diferentes tipos de arquivos carregados, havia:

  • quatro solicitações de recursos de .axd

  • quatro solicitações de recursos de .css

  • 12 solicitações de recursos de imagem

  • seis solicitações de recursos de .js (várias das quais duplicadas)

  • três solicitações de recursos de página para default.aspx (duas das quais integravam a negociação NTLM)

A maioria desses tipos de arquivo é bastante óbvia, com a possível exceção do tipo de recurso .axd. Um recurso .axd é parte de um novo recurso no ASP.NET versão 2.0. Um desenvolvedor pode adicionar um recurso, como arquivo de script ou folha de estilo, em um controle. No controle, o desenvolvedor usa a classe ClientScript para incluir um método chamado GetWebResourceUrl. Quando o controle é processado em tempo de execução, gera dinamicamente uma URL para o recurso. O próprio recurso é compilado no assembly de controle, logo, essa metodologia fornece um modo de levar esse recurso para fora do assembly e até o cliente tal como se fosse um arquivo separado localizado na servidor Web.

Conhecer as solicitações de recursos usadas pela página pode ajudá-lo a compreender onde e como as otimizações podem ser aplicadas. Você pode medir esse tipo de informações usando várias técnicas e ferramentas diferentes. Para este artigo, foi usada uma ferramenta freeware chamada Fiddler (em inglês). O Fiddler pode ser executado em uma estação de trabalho cliente e controla todas o solicitações HTTP feitas para uma página. Em seguida, exibe os resultados em uma grade, como mostra a figura a seguir.

Quando você alterar seu site para otimizá-lo, teste-o com o Fiddler. Para ter a ideia mais precisa sobre quais itens estão sendo solicitados, quais estão sendo armazenados em cache e o tamanho de cada item:

1. Exclua todos os arquivos temporários do navegador.

2. Inicie o Fiddler.

3. Solicite sua página.

   Dica

   Certifique-se de solicitar a página clicando em um link. Se você apenas clicar no botão Atualizar, o sistema torna a solicitar automaticamente os itens e não reflete com precisão as alterações de otimização que tiverem sido feitas.

Otimizando downloads de páginas

Depois des entender a composição da página, você pode usar diferentes métodos para otimizar o download para essa página. Em geral, a meta é minimizar o número de trajetos de ida e volta entre computadores cliente e servidor e reduzir o volume do tráfego de dados na rede. As orientações neste artigo incluem recomendações que podem ser amplamente aplicadas a várias diferentes implementações de Produtos e Tecnologias do SharePoint.

Há uma importante distinção a ser lembrada ao analisar essas recomendações e quaisquer outras otimizações personalizadas que você possa desenvolver. Classifique as técnicas otimização de página em uma destas duas categorias: primeira solicitação de página e solicitações de páginas subsequentes. As otimizações para a primeira solicitação de página são os tipos de otimizações implementados na primeira vez que a página é solicitada, mas que não afetam necessariamente as solicitações de páginas subsequentes. As otimizações de solicitações de páginas subsequentes são aquelas que podem aprimorar a experiência do usuário, seja esta a primeira ou a quinquagésima vez que um usuário solicita a página. Você precisa equilibrar a perda de funcionalidade em relação ao ganho obtido. Se só houver ganho na primeira vez que um usuário abre um site, talvez a otimização não compense a perda de funcionalidade.

Cache BLOB

O cache BLOB (objeto binário grande) em cache é discutido em mais detalhes adiante neste artigo. Resumindo, ele pode ser usado para aplicar diretivas de armazenamento em cache a itens em uma página que são armazenados em Produtos e Tecnologias do SharePoint. Se essas diretivas de cache estiverem incluídas, o navegador não tentará baixar os itens novamente até que o item em cache expire. Conforme foi ilustrado com o exemplo de home page anterior, quase todos os itens inclusos na home page padrão para o modelo de site de Portal de Colaboração tinham uma diretiva de armazenamento em cache associada a eles; por isso, eles não foram solicitados em visitas subsequentes à página. Para obter mais detalhes sobre a configuração do cache BLOB, consulte a página sobre Otimização do cache para ambientes WAN adiante, neste documento.

Compactação do IIS

Também é discutida em mais detalhes na seção Otimizando o cache para ambientes WAN deste documento. Entretanto, conforme observamos anteriormente, o padrão de configuração é o nível 0 de compactação. Experimente diferentes níveis de configurações de compactação até chegar àquele que otimize a compactação e minimize o impacto sobre as CPUs para os servidores Web. Em praticamente todos os casos, você pode usar um nível de compactação superior a 0. É importante lembrar, no entanto, que o nível de compactação só se aplica a arquivos dinâmicos, por exemplo, .axd e .aspx.

Hardware de 64 bits

As opções de hardware do farm também podem afetar a latência de solicitações. Os sistemas de 32 bits têm um limite de 2 gigabytes (GB) de memória RAM por aplicativo. Embora você possa estender o suporte a aplicativos para 3 GB de memória RAM, os Produtos e Tecnologias do SharePoint não oferecem suporte ao uso da alternância para /3GB . Situações de pouca memória podem afetar negativamente a latência de solicitações dos seguinte modos:

• Se a memória ficar restrita, isso poderá causar a reciclagem do pool de aplicativos do SharePoint. Força também a reciclagem do domínio do aplicativo ASP.NET, o que pode causar um grande atraso na resposta às solicitações dos usuários.

• Erros de falta de memória erros podem fazer com que o cache BLOB pare de oferecer conteúdo.

Usando hardware de 64 bits, você pode garantir a alocação e o uso de memória RAM suficiente para evitar esses erros.

Configurações de jardim de servidores Web

As configurações de jardim de servidores Web também podem inadvertidamente causar o funcionamento inconsistente do cache BLOB. Como somente um processo pode adquirir o bloqueio necessário para gerenciar o cache, o uso bem-sucedido do cache depende do thread que atenda a uma solicitação. Se um jardim, de servidores Web que não tenha o cache BLOB atender a uma solicitação, o conteúdo enviado em resposta não terá diretivas de armazenamento em cache associadas a ele. Isso aumenta o número de solicitações e a quantidade de dados enviados pela rede. Portanto, se você pretende usar o cache BLOB, não deve usar jardins de servidores Web.

Minimizar itens protegidos da página

Quando um usuário é autenticado nos Produtos e Tecnologias do SharePoint, ocorrem duas coisas. Primeiro, o sistema valida credenciais para determinar quem é o usuário. Em segundo lugar, o provedor de função enumera a lista de grupos do SharePoint aos quais o usuário pertence. Cada vez que uma página é solicitada, o provedor de função é novamente chamado para enumerar todos os grupos aos quais o usuário pertence.

Entretanto, essa chamada para associação de grupo pode ocorrer várias vezes em uma única página. Por exemplo, o modelo de site do Portal de Colaboração padrão exige duas chamadas para o provedor de função quando você acessa a home page—uma para a página em si e outra para as imagens da página. Cada imagem que estiver armazenada em uma biblioteca do SharePoint e na página forçará uma chamada adicional para o provedor de função para verificar as permissões, mesmo que todas as imagens estejam armazenadas na mesma biblioteca de imagens. Essa verificação ocorre se as imagens forem adicionadas como campos de página—ou seja, fizerem parte do conteúdo da página—ou se forem adicionadas à página mestra do site.

Um site desenvolvido para um ambiente com largura de banda limitada ou alta latência deve ser projetado para minimizar o número de imagens usadas na página. Muitos sites usam várias imagens como parte da página mestra para criar diferentes efeitos visuais. Como a latência aumentará com o maior número de verificações de segurança, crie sites para esses ambientes usando o menor número possível de imagens.

Minimizando o número e o tamanho das imagens

Conforme descrito na seção anterior, você deve minimizar o número de imagens no seu site. Para ajudar nesse esforço, você pode incorporar várias imagens em um único arquivo e, em seguida, referenciar imagens individuais na sua página. Não só o tamanho do download de arquivos diminuirá, mas menos arquivos significarão menos tráfego de rede. É mais complicado criar páginas usando essa técnica, mas em situações nas quais qualquer trajeto de ida e volta e tamanho de arquivo é importante, ela pode ser um meio importante para ajudar a melhorar o desempenho. A figura a seguir mostra um exemplo de arquivo de imagem única que contém várias imagens.

A figura a seguir mostra como essa imagem será alterada posteriormente para ser exibida como imagem individual em uma tabela.

A manipulação de imagens foi totalmente feita por meio de classes de folhas de estilo. Havia duas classes primárias usadas em elementos de div e img em cada célula da tabela. Essas classes são:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

Cada imagem tem uma classe associada a ela com base na identificação (ID) para a imagem. Esse estilo recorta a imagem e define um deslocamento da imagem inicial no cluster. Essas classes são:

#person {

   border:none;

   clip:rect(0, 49, 49, 0);

}

#keys {

   clip:rect(0, 99, 49, 50);

   left:-50px;

}

#people {

   clip: rect(0, 149, 49, 100);

   left:-100px;

}

#lock {

   clip:rect(0, 199, 49, 150);

   left:-150px;

}

#phone {

   clip:rect(0,249, 49, 200);

   left:-200px;

}

#question {

   clip:rect(0, 299, 49, 250);

   left:-250px;

}

O HTML para a tabela inclui as marcas div e img com os devidos valores de identificação e nomes de classes, da seguinte maneira:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Várias propriedades e produtos da Microsoft para a Web agora usam essa técnica, incluindo o Microsoft Passport Network e o OWA (Microsoft Office Outlook Web Access). A equipe do MSN realizou testes de desempenho para analisar o impacto das alterações e observou uma melhora de 50% a 75% no tempo de carregamento para a primeira página.

Há um ponto importante a ser considerado se você estiver criando suas páginas no Microsoft Office SharePoint Designer 2007. Quando você cria uma nova página no Office SharePoint Designer 2007, ele adiciona automaticamente a seguinte marca do esquema XHTML à página:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

Se você usar esse esquema, as imagens não serão alinhadas corretamente. Você deve remover o atributo xmlns da marca HTML para que as imagens apareçam conforme o esperado.

Atraso no download do core.js

O principal arquivo de script cliente incluído no Office SharePoint Server 2007 chama-se core.js. É o maior arquivo de script, com aproximadamente 257 KB descompactado e aproximadamente 54 KB compactado. Em determinadas situações, talvez seja possível atrasar o download do arquivo core.js. Quando você faz isso, a página é processada mais rapidamente, porque o download do arquivo core.js não é iniciado até que a página seja aberta no navegador. Isso permite que o usuário exiba a página e inicie a leitura do conteúdo mais rapidamente. Essa técnica é muito útil em cenários de Internet com usuários anônimos. Inversamente, os usuários autenticados precisam ter o core.js baixado na hora do carregamento da página para essa funcionalidade ou elementos de interface do usuário como o menu Ações do Site.

Você pode usar as seguinte etapas para implementar essa técnica.

1. Crie uma página de layout personalizada que não use o core.js. Essa página de layout será usada com a home page, para que os visitantes iniciais do site não precisem aguardar o download do core.js imediatamente. Ela deve ser compatível com a home page existente; portanto, a nova página de layout deve ter o mesmo tipo de conteúdo associado da página de layout atualmente em uso.

   Dica

   Por padrão, em um site do Portal de Colaboração, o tipo de conteúdo da página de boas-vindas é especificado.

2. Adicione a seguinte marca à página: <SharePointWebControls:ScriptLink runat ="servidor"/> . Isso instrui o sistema a não usar o core.js a menos que esteja relacionado.

3. Crie um controle personalizado para procurar usuários autenticados. O controle é muito simples e contém essencialmente o seguinte código (mostrado em C#):

   if (HttpContext.Current.Request.IsAuthenticated)   
       Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
   

4. Em cada servidor Web, ponha o controle no GAC (Cache de Assembly Global) e, em seguida, adicione uma entrada SafeControl para ele no arquivo Web.config para o aplicativo Web no qual ele será usado.

5. Adicione o controle personalizado à página de layout personalizada criada na etapa 1.

6. Adicione um IFRAME à página de layout. Ele deve fazer referência a uma página que tenha o seguinte conteúdo:

   <body>
   <SharePoint:ScriptLink name="core.js" runat="server" />
   <script language="javascript">
    DisableRefreshOnFocus();
   </script>
   </body>
   

7. Faça check-in e publique a página de layout personalizada.

8. Baseie a home page do site na nova página de layout.

Após executar as etapas acima, teste a home page do site para verificar se ela funciona. Um usuário anônimo inicial não deverá ver nenhuma referência ao arquivo core.js na origem da página, mas a finalização deverá ocorrer no cache do navegador.

Além disso, considere o seguinte antes de empregar essa técnica:

• As páginas mestras do site e do sistema devem ser diferentes; caso contrário, todas as páginas em _layouts não funcionarão corretamente.

• Certifique-se de que a página mestra não contenha controles que exijam o arquivo core.js no momento do carregamento para funcionar.

• Certifique-se de que a página mestra não tenha controles ScriptLink que carreguem ou façam referência a core.js.

Para obter mais detalhes e um exemplo de código, consulte o Blog da ECM (Equipe de Gerenciamento de Conteúdo Corporativo) da Microsoft (em inglês) (https://go.microsoft.com/fwlink/?linkid=106008\&clcid=0x416) (em inglês).

Otimizando páginas de exibição de lista

A equipe de Serviços Microsoft trabalhou para quantificar e melhorar o desempenho dos tempos de processamento de páginas de exibição de lista. Uma página de exibição de lista é a página AllItems.aspx usada por cada lista e biblioteca para habilitar a procura de conteúdo. O tempo de processamento dessa página pode variar amplamente com base no número e no formato das colunas visíveis no modo de exibição. Como exemplo, as opções de exibição e a habilitação de ícones de presença podem afetar bastante o tempo de processamento. O processamento de grupos recolhidos demorou significativamente mais do que o de grupos expandidos e ambos os foram mais lentos do que o processamento sem nenhum agrupamento.

Esses tipos de nuances demonstram por que é importante considerar cuidadosamente a forma como os modos de exibição são construídos em páginas de exibição de lista, especialmente em vínculos rede lenta. Ao trabalhar com listas que contêm muitos dados, é importante adaptar cuidadosamente todos os modos de exibição, especialmente a exibição padrão. Em termos gerais, você pode acelerar o tempo de processamento de páginas de exibição de lista:

• Mostrando menos colunas.

• Excluindo quaisquer colunas que incluam informações sobre presenças.

• Usando um link (mas não o menu editar) para exibir os detalhes do item.

A tabela a seguir descreve personalizações que reduzem o tempo exigido para o processamento de um modo de exibição.

Item	Descrição
Tipo de modo de exibição	Crie um modo de exibição como folha de de dados, em vez da exibição padrão.
Modo de exibição: Limite de Itens	Qualquer volume acima de 1.000 provavelmente será processado mais lentamente. Em uma conexão lenta é importante experimentar para encontrar o equilíbrio correto entre o volume de dados mostrado por vez e o número de trajetos de ida e volta necessários à exibição de todos os dados. Quanto mais linhas forem mostradas por vez, menos trajetos de ida e volta, porém maiores páginas.
Modo de exibição: Filtro	Use [Hoje] e [Eu] para filtrar itens por atualização ou atribuição. Use campos de status para mostrar somente itens ativos nos modos de exibição padrão.
Modo de exibição: Colunas	Use apenas o número necessário de colunas. Crie uma exibição padrão com poucas colunas que permita um alto nível de navegação com base no qual as pessoas possam fazer buscas detalhadas.

A tabela a seguir descreve personalizações que aumentarão o tempo exigido para o processamento de um modo de exibição. Cada coluna adicional aumenta um pouco o tempo de processamento: até meio segundo por coluna em uma conexão de rede rápida, considerando-se uma lista de 1.000 itens. Algumas colunas custam mais, como se observa na tabela.

Item	Descrição
Agrupar por	O agrupamento adiciona HTML e JScript, diminuindo o processamento para listas grandes. A ação de recolher todos os grupos por padrão na verdade aumenta o tempo de processamento, devido às operações adicionais no modelo de objeto do navegador.
Coluna – título vinculado ao item com menu de edição	A opção "vinculado ao item com menu de edição" é a mais demorada; a opção semelhante "vinculado ao item" não aumenta de forma perceptível o tempo de processamento.
Coluna – Procurar Usuário com Presença	A adição de um campo de pesquisa de usuário com presença adiciona HTML a cada link para abrir o menu de presença. Além disso, também usa largura de banda para determinar a disponibilidade da presença.

A tabela a seguir descreve personalizações com impacto relativamente pequeno sobre o tempo exigido para o processamento de um modo de exibição.

Item	Descrição
Classificar, totais	A aplicação de várias classificações e totais aumentará consideravelmente o tempo de processamento, mas o custo de cada aplicação normalmente é inferior a um segundo, considerando-se uma lista de 1.000 itens.

Otimizando o cache para ambientes WAN

Há várias diferentes opções de cache no Office SharePoint Server 2007. Várias delas são destinadas a melhorar a produtividade no pipeline de processamento—do momento em que uma solicitação é recebida no servidor até o momento em que uma resposta começa a ser transmitida de volta ao computador cliente. Embora esse seja um aspecto importante do desempenho geral do site, esta seção se concentra no armazenamento em cache considerando seu relacionamento com:

• A função da configuração do servidor no cache do cliente.

• O controle do tamanho dos itens transmitidos na rede do servidor para o cliente.

Cache BLOB

O cache BLOB é um mecanismo disponível apenas com os recursos de publicação do Office SharePoint Server 2007. Isso o torna um candidato ideal para sites de portal corporativos com base no modelo de site do Portal de Colaboração e sites de Internet com base no modelo de site do Portal de Publicação. O cache BLOB permite configurar diretivas de cache associadas a itens servidos de listas de sites de publicação, por exemplo, a biblioteca de Páginas e Imagens do Conjunto de Sites. Quando o navegador no computador cliente encontra uma diretiva de cache, detecta que o item que ele está recuperando pode ser salvo localmente e não precisa ser novamente solicitado até que a diretiva expire. Em ambientes geograficamente distribuídos, isso é extremamente importante, pois reduz o número de itens solicitados e enviados pela rede.

Quando o cache BLOB no Office SharePoint Server 2007 está ativado, ocorrem algumas ações diferentes. Primeiramente, cada vez que um item com capacidade de armazenamento em cache é solicitado, o Office SharePoint Server 2007 pesquisa a unidade de disco rígido do servidor Web que recebeu a solicitação para ver se há uma cópia local. Se houver, o arquivo é transmitido diretamente do disco local para o usuário. Se ele ainda não estiver no disco local, é feita uma cópia do item do banco de dados SQL onde ele está armazenado e o item será enviado ao usuário autor da solicitação. A partir desse ponto, todas as solicitações para esse item podem ser servidas diretamente do servidor Web até que o valor de capacidade de armazenamento em cache do item indique que ele expirou. Isso resulta no melhor desempenho no farm de servidores, reduzindo a contenção no servidor do banco de dados.

A outra ação é anexar ao item um cabeçalho de capacidade de armazenamento em cache quando ele é enviado ao cliente. Esse cabeçalho instrui o navegador sobre o tempo em que o item deve ser armazenado em cache. Por exemplo, se uma figura tiver um valor de capacidade de armazenamento em cache de três dias, o navegador usará a cópia da imagem que possui no seu cache local se a imagem for novamente solicitada nos próximos três dias; ele não a solicitará novamente ao servidor.

Ao testar seu site para verificar quais itens são armazenados em cache e como isso está ocorrendo, você pode usar o recurso Fiddler (em inglês) (http://www.fiddlertool.com) (em inglês). A captura de tela a seguir mostra uma captura do Fiddler em um site simples do SharePoint usado para publicação. O site foi criado com o uso do modelo de site do Portal de Colaboração padrão. Algum conteúdo de texto adicional foi adicionado à página e várias imagens foram adicionadas à página mestra.

Há várias informações importantes contidas no aplicativo Fiddler.

• A coluna # à esquerda indica que houve um total de 44 solicitações HTTP feitas pelo navegador para que o servidor processe a página.

• A coluna Resultado mostra o código de resultado HTTP retornado da solicitação para o item; um resultado 200 significa que o item foi recuperado com êxito.

• A coluna URL indica qual item específico estava sendo solicitado.

• A coluna Corpo indica o tamanho de cada item.

• A coluna Cache mostra a diretiva de cache que estava associada a cada item. Os dados na coluna Cache mostram que vários itens têm uma diretiva de cache associada a eles; ou seja, eles têm um atributo max-age superior a 0. As diretivas de cache são expressas em segundos. Isso significa que, na página ilustrada, vários itens estão configurados para serem armazenados em cache por 365 dias (60 segundos em um minuto, 60 minutos em uma hora, 24 horas em um dia = 60x60x24 = 86.400x365 = 31.536.000).

Observe que todos os itens com essa diretiva de cache residem no diretório _layouts. O motivo para essa configuração é a maneira como o diretório virtual _layouts/images é configurado no IIS. Quando você cria um novo aplicativo Web, o Office SharePoint Server 2007 cria automaticamente vários diretórios virtuais que são mapeados para pastas nos discos físicos do servidor Web. Quando ele cria o diretório virtual _layouts/images, adiciona uma diretiva de cache que se aplica a todo o diretório. A captura de tela a seguir mostra a configuração para o diretório no snap-in Gerenciador do IIS.

Como todos esses itens têm uma diretiva de armazenamento em cache não zero associada, na próxima vez que a página for solicitada, o navegador usará a cópia do item do seu cache de navegador local em vez de solicitá-la novamente ao servidor. A captura de tela a seguir mostra um instantâneo do Fiddler quando a página é solicitada pela segunda vez.

Como os dados do Fiddler mostram, o número de itens solicitados foi significativamente reduzido—de 44 para 1. Um ponto importante a ser observado é que o número de solicitações feitas pode variar dependendo de como a página é solicitada. Se você usar o botão Atualizar no navegador, todos os itens provavelmente serão novamente solicitados, exista ou não uma versão do item armazenada em cache local. Inversamente, se a página for solicitada pela navegação até ela usando um link ou atalho, somente os itens não armazenados em cache serão solicitados.

O outro ponto mostrado pelos dados do Fiddler é que o navegador está solicitando ao servidor as outras imagens na página mestra que ele já tem em seu cache local; o código de resposta 304 indica isso. Significa que o navegador fez uma solicitação condicional para um item. A resposta 304 significa que a versão existente no servidor não foi modificada com base na versão do cliente; portanto, não precisa ser baixada novamente. Embora o arquivo não seja baixado na rede, ele mesmo assim gerou um trajeto de ida e volta para o servidor, para determinar se a cópia local é atual. Em ambientes geograficamente distribuídos, os trajetos de ida e volta de servidores são onerosos; portanto, a meta é reduzi-los tanto quanto possível. Se uma diretiva de armazenamento em cache diferente de zero for adicionada a cada um dos itens restantes (sem considerar a página, que é sempre retornada pelo servidor), essa meta pode ser alcançada. O recurso de cache BLOB é o que adiciona essa diretiva de armazenamento em cache.

Você configura o cache BLOB usando o arquivo Web.config para o aplicativo Web no qual o cache será usado. Abra o arquivo Web.config em um editor de texto como o Bloco de Notas e procure a entrada BlobCache. Por padrão, ela será:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

Os atributos usados no elemento BlobCache têm os seguintes significados:

• location **   **Refere-se ao local na unidade de disco rígido do servidor Web onde os itens armazenados em cache serão armazenados.

• path   Expressão regex dos tipos de arquivos que devem ser armazenados em cache.

• maxSize    O tamanho, em GB, que o cache tem permissão para usar.

• enabled **   **Definir como true para habilitar o cache BLOB.

O seguinte atributo adicional—não incluído por padrão—é necessário para definir um valor de expiração do armazenamento em cache em individual itens:

• max-age   O tempo, em segundos, durante o qual os itens devem ser armazenados em cache no computador cliente.

Com a configuração do atributo max-age com um valor diferente de zero, os itens com capacidade de armazenamento em cache têm associado a si um valor de expiração do armazenamento em cache para que um navegador não precise mais baixar o item, ou até mesmo verificar se ele tem a versão mais atual. Por exemplo, suponha que você queria habilitar o armazenamento em cache e alocar até 100 MB no servidor Web para armazenar itens. Eles devem expirar uma vez por dia, e além dos tipos predefinidos armazenados em cache, arquivos .htc também devem ser armazenados em cache. Para oferecer suporte a esses requisitos, especifique os seguintes atributos BlobCache:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

Observe que essa alteração para o arquivo Web.config precisa ser feita em cada servidor Web do farm. Na maioria dos casos, o cache BLOB começará a funcionar imediatamente, mas é mais seguro usar o comando iisreset quando você implementar as alterações. A captura de tela a seguir mostra dados do Fiddler para a mesma solicitação de página mostrada anteriormente, apenas com o cache BLOB habilitado conforme descrito.

Observe que todos os itens da biblioteca /SiteCollectionImages têm agora um código de status HTTP 200, indicando que foram baixados com êxito. Além disso, todos eles agora têm associada a eles uma diretiva de armazenamento em cache que especifica que eles não expirarão durante um dia (8.400 segundos). Se a página for novamente solicitada, o Fiddler mostra que nenhuma das imagens é solicitada novamente; o número total de solicitações de serviço para a página passou, portanto, de 44 para três e duas delas são apenas da negociação de autenticação NTLM que ocorre entre o servidor Web e o aplicativo cliente. A figura a seguir mostra dados do Fiddler quando a página é novamente solicitada.

Além disso, considere os seguintes pontos ao trabalhar com o cache BLOB:

• Ele requer um esforço adicional para configuraro, pois você deve atualizar o arquivo Web.config em cada servidor Web. No entanto, os benefícios compensam o esforço.

• Pesquise o conteúdo do seu site e determine se há outros tipos de arquivos que também devam ser atendidos no cache. Um bom exemplo são os arquivos .htc. Como os arquivos .htc são usados em muitos sites de publicação, você deve adicionar esse tipo de arquivo à lista dos tipos arquivos armazenadas em cache.

• O cache BLOB funciona somente em itens armazenados nas bibliotecas do SharePoint; ele não pode ser usado para armazenar em cache conteúdos de outras fontes.

• Por padrão, algumas listas não funcionam para usuários anônimos. Se houver usuários anônimos que acessam o site, as permissões deverão ser configuradas manualmente para as seguintes listas, para que seus itens sejam armazenados em cache:

  • Galeria de Páginas Mestras

  • Biblioteca de Estilos

Há duas outras opções de configuração às quais você deve estar atento quando estiver trabalhando com o cache BLOB. A primeira está relacionada à limpeza do cache BLOB. Se o cache precisar ser limpo para um site específico, vá até esse conjunto de sites e clique no menu Ações do Site…Configurações do Site…Modificar Todas as Definições do Site. Na lista de tarefas Administração do Conjunto de Sites, clique no link para o cache de objetos do conjunto de sites. Na seção Redefinir Cache Baseado em Disco, marque a caixa Forçar este servidor a redefinir seu cache baseado em disco e clique no botão OK.

Se você estiver pensando em usar jardins de servidores Web em um farm do SharePoint, também deverá estar ciente de que isso provocará o funcionamento do cache BLOB de uma forma aparentemente inconsistente. Quando mais de um jardim de servidores Web é configurado no farm de servidores, esse fato gera um problema, pois somente um deles pode adquirir o bloqueio necessário para gerenciar o cache BLOB. Como resultado, poderá parecer que o cache BLOB está funcionando apenas de forma intermitente. O uso bem-sucedido do cache BLOB torna-se dependente do thread que atende a uma solicitação.

Compactação do IIS

Diferentemente das versões anteriores dos Produtos e Tecnologias do SharePoint, a compactação do IIS agora é automaticamente ativada quando você instala os Produtos e Tecnologias do SharePoint. Depois que um site tiver sido acessado por alguns usuários, você pode verificar se a compactação está funcionando visualizando o diretório %WINDIR%\IIS Temporary Compressed Files em um servidor Web. Ele deve conter vários arquivos, o que indica que arquivos estáticos foram solicitados e que o IIS compactou uma cópia deles e os armazenou na unidade local. Quando esse arquivo é solicitado novamente, seja pelo mesmo usuário ou não, a versão compactada do arquivo é servida diretamente dessa pasta. Os arquivos dinâmicos também podem ser compactados, mas isso sempre ocorre dinamicamente; não são mantidas cópias no servidor Web local.

A compactação pode resultar em economia significativa de largura de banda. Por exemplo, o arquivo core.js está incluído em cada página do SharePoint. Descompactado, ele tem 257 KB; após a compactação, o arquivo tem somente 54 KB sem executar ajuste adicional para compactação do IIS. O core.js deve ser armazenado em cache depois que o usuário visita o site pela primeira vez, mas esse exemplo ilustra como a compactação pode ajudar significativamente em cenários de baixa largura de banda.

Quando os Produtos e Tecnologias do SharePoint são instalados, o programa de instalação configura o IIS para compactar os tipos de arquivos estáticos .htm, .html e .txt; ele compacta os tipos de arquivos dinâmicos .asp e .exe. Pesquisando os tipos de arquivos amplamente usados na sua implementação, poderá ser vantajoso compactar outros tipos de arquivos. Por exemplo, provavelmente também é interessante compactar os tipos de arquivos estáticos .css e .js; também pode ser interessante compactar os tipos de arquivos dinâmicos .axd e .aspx.

Para adicionar um tipo arquivo estático ou dinâmico à lista de tipos que serão compactados, use o arquivo adsutil.vbs que está na pasta %SystemDrive%\Inetpub\AdminScripts por padrão em cada servidor Web. O exemplo a seguir mostra o Microsoft Windows Server 2003, inclusive arquivos css e js na lista dos tipos de arquivos estáticos compactados:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

O exemplo a seguir mostra a inclusão de arquivos .aspx e .axd à lista de tipos de arquivos dinâmicos:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

Ao alterar os tipos de arquivos que são compactados, certifique-se de incluir apenas arquivos adequados à compactação. Como exemplo, arquivos .jpg não são bons candidatos, pois o formato do arquivo já é inerentemente compactado. Além disso, tipos de arquivo do 2007 Microsoft Office System como docx, xlsx e pptx não são uma boa escolha para compactação, pois os arquivos não são servidos diretamente do servidor; em vez disso, eles são roteados por diferentes filtros ISAPI usados para gerenciar a experiência do usuário final com ampla integração de conteúdo do Microsoft Office. Além disso, no 2007 Microsoft Office System, esses tipos de arquivos são inerentemente compactados.

Além de controlar os tipos de arquivos compactados, também é possível controlar o nível de compactação usado em tipos de arquivos dinâmicos. A taxa de compactação usada baseia-se em uma escala de 0 a 10. Quanto maior o nível de compactação, menores serão os arquivos. No entanto, o inconveniente é que maiores níveis de compactação também consomem mais CPU, portanto, você terá maior utilização de CPU na compactação para criar arquivos menores. Quando a compactação do IIS está habilitada, ele a configura para usar um nível de compactação 0. Historicamente, o nível de compactação ideal com os Produtos e Tecnologias do SharePoint é 9. Para alterar o nível de compactação, use o arquivo de script adsutil.vbs descrito anteriormente neste artigo. O exemplo a seguir mostra a alteração do nível de compactação para 9.

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

  Dica

  Essa configuração não altera a compactação de arquivos estáticos.

Para obter mais informações, consulte a página sobre o Uso da compactação HTTP (IIS 6.0) (em inglês) (https://go.microsoft.com/fwlink/?linkid=108705\&clcid=0x416) (em inglês).

Combinando o cache BLOB com a compactação do IIS

Ativando o cache BLOB você pode reduzir significativamente o número de trajetos de ida e volta do servidor e de arquivos enviados pela rede quando os usuários procuram um site do SharePoint. Quando a compactação é usada em conjunto com o cache BLOB, reduz também o volume de tráfego de arquivos enviados aos clientes. A combinação dos dois pode reduzir muito o tráfego de rede e a contenção de recursos da rede e do servidor.

Baixar este manual

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

• Planejamento e arquitetura para o Office SharePoint Server 2007, parte 2

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

Consulte também

Conceitos

Otimizando Web Parts personalizadas para a WAN
Estendendo as soluções globais do Office SharePoint Server com os softwares Office Outlook 2007 e Office Groove
Soluções globais com suporte no Office SharePoint Server