Para desempenho geral, geralmente é útil escalar a arquitetura e não apenas incluir partes de hardware individuais. Não importa a quantidade de hardware incluída em uma única máquina, esse hardware ainda terá um nível máximo de desempenho.
A seção discute os problemas de arquitetura de rede a serem considerados durante a introdução da funcionalidade do Caching Proxy em sua rede.
Se o Web site de sua empresa for popular, poderá haver maior demanda por seu conteúdo do que um único Servidor Proxy possa atender de forma eficiente, resultando em tempos de resposta lentos. Para otimizar o desempenho da rede, considere incluir máquinas do Caching Proxy com cluster, com equilíbrio de carga ou utilizar uma arquitetura de cache compartilhada com RCA (Remote Cache Access) em sua arquitetura de rede geral.
Uma forma de escalar a arquitetura é fazer cluster de Servidor Proxy e utilizar o componente Load Balancer para equilibrar a carga entre eles. Fazer cluster de Servidor Proxy é uma consideração de design útil não apenas por razões de desempenho e escalabilidade, mas também por motivos de redundância e confiança. Um único Servidor Proxy representa um único ponto de falha; se ele falhar ou ficar inacessível devido a uma falha na rede, os usuários não poderão acessar seu Web site.
Considere também uma arquitetura de cache com RCA. Uma arquitetura de cache compartilhada espalha a cache virtual total entre vários servidores Caching Proxy que geralmente utilizam um protocolo entre caches como o ICP (Internet Cache Protocol) ou o CARP (Cache Array Routing Protocol). O RCA foi projetado para aumentar as proporções de correspondências da cache com cluster, fornecendo uma grande cache virtual.
Os benefícios de desempenho resultam da utilização de uma matriz RCA de Servidor Proxy em contraste com um único Caching Proxy independente ou até mesmo um cluster de máquinas do Caching Proxy independentes. Geralmente, os benefícios de desempenho são causados pelo aumento do tamanho da cache virtual total, que maximiza a proporção de correspondência da cache e minimiza a inconsistência e a latência da cache. Com o RCA, somente uma cópia de um documento específico reside na cache. Com um cluster de Servidor Proxy, o tamanho da cache total é aumentado, mas vários servidores proxy provavelmente buscarão e armazenarão em cache as mesmas informações. Portanto, a proporção de correspondência da cache total não é aumentada.
O RCA é comumente utilizado em grandes cenários de hospedagem de conteúdo corporativo. No entanto, a utilidade do RCA não está limitada a implementações corporativas extremamente grandes. Considere utilizar o RCA se a carga de sua rede exigir um cluster de servidores da cache e se a maioria dos pedidos for correspondências da cache. Dependendo da configuração de sua rede, o RCA nem sempre melhora o desempenho corporativo devido a um aumento no número de conexões TCP que um cliente utiliza quando o RCA é configurado. Isto ocorre porque um membro do RCA é responsável não apenas por atender às URLs para as quais ele tem a melhor pontuação, mas também deve encaminhar pedidos para outros membros ou clusters se obtiver um pedido para uma URL para a qual ele não tem a melhor pontuação. Isto significa que qualquer membro de uma matriz RCA pode ter mais conexões TCP abertas do que teria se funcionasse como um servidor independente.
As principais contribuições para um melhor desempenho resultam das capacidades de armazenamento em cache do Caching Proxy. No entanto, a cache do Servidor Proxy pode se tornar um gargalo se não estiver configurada corretamente. Para determinar a melhor configuração da cache, deve ser feito um grande esforço para analisar as características do tráfego. O tipo, tamanho, quantidade e atributos do conteúdo afetam o desempenho do Servidor Proxy em termos de tempo gasto para recuperar documentos de servidores de origem e a carga no servidor. Quando você conhece o tipo de tráfego que o Caching Proxy vai aceitar ou atender a partir de seu cache, é possível incluir como fatores essas características durante a configuração do Servidor Proxy. Por exemplo, sabendo que 80% dos objetos que estão sendo armazenados em cache são imagens (*.gif ou *.jpg) e que têm aproximadamente 200 KB de tamanho pode ajudar a ajustar os parâmetros de armazenamento em cache e determinar o tamanho da cache. Além disso, saber que a maioria do conteúdo são páginas dinâmicas personalizadas que não são candidatas a armazenamento em cache também é relativo ao ajuste do Caching Proxy.
Analisar as características do tráfego permite determinar se é preciso utilizar uma memória ou cache de disco para otimizar o desempenho de seu cache. Além disso, a familiaridade com as características de tráfego da rede permite determinar se o desempenho aumentado pode resultar da utilização do recurso de armazenamento em cache dinâmico do Caching Proxy.
As caches de disco são apropriadas para sites com grandes quantidades de informações a serem armazenadas em cache. Por exemplo, se o conteúdo do site for grande (maior do que 5 GB) e houver uma taxa de correspondência da cache de 80 a 90%, isto indica que é recomendada uma cache de disco. No entanto, sabe-se que utilizar a cache de memória (RAM) é mais rápido e a existência de muitos cenários ao utilizar uma cache somente memória é recomendável para grandes sites. Por exemplo, se a taxa de correspondência da cache do Caching Proxy não for tão importante ou se estiver sendo utilizada uma configuração de cache compartilhada, a cache de memória será útil.
O Caching Proxy pode armazenar em cache e invalidar o conteúdo dinâmico (resultados de JSP e de servlet) gerado pela cache dinâmica do WebSphere Application Server, fornecendo uma extensão virtual da cache do Application Server para caches baseadas em rede. Ativar o armazenamento em cache de conteúdo gerado dinamicamente é útil para o desempenho da rede em um ambiente no qual há muitos pedidos por páginas da Web públicas geradas dinamicamente, que expiram com base na lógica de aplicativo ou em um evento como uma mensagem de um banco de dados. A duração da página é finita, mas um disparo de expiração não pode ser definido no momento de sua criação; portanto, hosts sem um armazenamento em cache dinâmico e um recurso de invalidação devem designar este tipo de página como tendo um valor de tempo de vida zero.
Se tal página gerada dinamicamente for solicitada mais de uma vez durante seu ciclo de vida por um ou mais usuários, o armazenamento em cache dinâmico fornecerá uma grande remoção de trabalho e reduzirá a carga de trabalho nos hosts de conteúdo de sua rede. A utilização de armazenamento em cache dinâmico também melhora o desempenho da rede, fornecendo resposta rápida aos usuários, eliminando atrasos da rede e reduzindo o uso de largura de banda devido a um tráfego menos intenso na Internet.