Inovações dentro do alcance: Usando o WebSphere eXtreme Scale para Aprimorar o Desempenho do WebSphere Portal e do IBM Web Content Manager

O IBM® Web Content Manager no IBM WebSphere® Portal pode usar instâncias de dynacache para armazenar o conteúdo renderizado recuperado do Web Content Manager quando o armazenamento em cache avançado está ativado. Esse armazenamento em cache melhora o tempo de resposta e reduz a carga no banco de dados. O WebSphere eXtreme Scale e o dispositivo de armazenamento em cache XC10 oferecem uma implementação de dynacache que armazena o conteúdo em cache em uma grade de dados elástica em vez de usar a implementação padrão do dynacache, que armazena o conteúdo em cache no espaço de heap do IBM WebSphere Application Server ou no disco. Este artigo examina os benefícios significativos de desempenho obtidos ao passar o conteúdo de cache avançado do WebSphere Portal em uma grade de dados hospedadas por um dispositivo de armazenamento em cache XC10, sem necessidade de alterações no código do aplicativo. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Benjamin Parees, Senior Software Engineer, IBM

Ben Parees é engenheiro de software senior e possui 11 anos de experiência na IBM. Atua há dois anos como desenvolvedor do produto WebSphere eXtreme Scale e trabalha com o produto XC10 desde a sua concepção. Como desenvolvedor, seu foco é a área de tecnologia de persistência em disco. Além disso, atuou como arquiteto de integração de produtos. Seu foco principal era ajudar os produtos IBM a aprimorarem soluções de armazenamento em cache WXS e XC10. Ben possui mestrado em Ciência da Computação pela Universidade Estadual da Carolina do Norte e cursou Ciência da Computação na Universidade Estadual da Pensilvânia.



Wanjun Wang, System Verification Test Architect, IBM

Wanjun Wang é arquiteto de teste de verificação do WebSphere Portal System. Trabalha há anos com portal/gerenciamento de conteúdo da web/personalização e outros tipos de middleware. Supervisiona a estratégia de teste de sistema para as liberações do portal/WCM, que inclui configurações de teste, execuções de confiabilidade e automação. Também está ativamente envolvido na consultoria para clientes de alto perfil para grandes implementações. Wanjun trabalha no laboratório IBM Research Triangle Park, EUA.



Ramakrishna Boggarapu, Advisory Software Engineer, IBM

Rama Boggarapu é consultor em engenharia de software e possui nove anos de experiência na IBM. Recentemente, passou a fazer parte da equipe de desenvolvimento do WebSphere eXtreme Scale e trabalha na equipe de integração atualmente. Antes disso, Rama atuou como Team Leader de suporte nível 2 do WebSphere Application Server e foi reconhecido como especialista nos assuntos contêiner da web, gerenciamento de sessões, cache dinâmico e componentes de carregador de classes. Ele é bacharel em Eletrônica e Comunicações.



16/Jul/2012

Cada parte do artigo Inovações dentro do alcance apresenta novas informações e discussões sobre tópicos relacionados a tecnologias emergentes, tanto do ponto de vista do desenvolvedor como do praticante, mais observações por trás dos bastidores dos produtos IBM® WebSphere® de ponta.

Introdução

O IBM WebSphere eXtreme Scale é a plataforma estratégica de armazenamento em cache baseado no software da IBM. O WebSphere eXtreme Scale é uma grade de dados na memória baseada em Java™ que processa, particiona, replica e gerencia dinamicamente os dados do aplicativo e a lógica de negócios ao longo de centenas de servidores. O WebSphere eXtreme Scale fornece a maior flexibilidade ao longo de uma ampla variedade de cenários de armazenamento em cache.

O WebSphere eXtreme Scale é totalmente elástico. É possível adicionar ou remover servidores da grade de dados. Automaticamente, ela será redistribuída para aproveitar melhor os recursos disponíveis e, ao mesmo tempo, continuar fornecendo acesso contínuo aos dados, juntamente com uma tolerância a falhas totalmente integrada. O WebSphere eXtreme Scale fornece recursos comprovados para datacenters diversos e se integra facilmente a outros produtos de infraestrutura de aplicativos da IBM para fornecer uma solução de armazenamento em cache elástico eficiente e de alto desempenho para a sua empresa.

O dispositivo IBM WebSphere DataPower® XC10 fornece os benefícios do WebSphere eXtreme Scale em um fator de forma de dispositivo fácil de implementar. Cada dispositivo XC10 fornece 240 GB de capacidade de cache e uma interface com o usuário de gerenciamento simplificado para a criação e o monitoramento de grades de dados e para o bom funcionamento do dispositivo. Os dispositivos podem ser agrupados em coletivos altamente disponíveis, fornecendo recurso de failover e aumentar a capacidade geral e o rendimento do cache.

O IBM Web Content Manager está incluso no IBM WebSphere Portal para fornecer uma solução robusta de gerenciamento de conteúdo da web. Ele é usado para criar, gerenciar e fornecer conteúdo para o seu website. É possível criar conteúdo usando o portlet de criação de conteúdo da web ou criando a sua própria interface customizada de criação. O conteúdo da web armazenado nos sistemas externos de gerenciamento de conteúdo também pode ser referido dentro de um sistema do Web Content Manager. É possível entregar o seu conteúdo da web usando os portlets de visualizador de conteúdo da web ou o servlet do Web Content Manager ou pré-renderizar o seu site para HTML. O portlet do visualizador de conteúdo da web é a opção mais usada para exibir o conteúdo do Web Content Manager. O cache básico do Web Content Manager é configurado por padrão e usado para a renderização do servlet. O Web Content Manager só suporta o cache avançado para renderizar por meio de um portlet. Sendo assim, o portlet do visualizador de conteúdo da web pode se beneficiar muito com a melhoria no cache avançado.


Limitações do armazenamento em cache do servidor de aplicativos tradicional

O armazenamento em cache do conteúdo diretamente na JVM do servidor de aplicativos possui um benefício óbvio: o acesso ao conteúdo em cache é extremamente rápido, porque não há necessidade de passagem na rede. Infelizmente, também apresenta várias limitações (Figura 1):

  • O tamanho máximo do cache é limitado ao heap disponível na JVM. Um heap de JVM grande e muito cheio pode levar a pausas longas para coleta de lixo, deixando o tempo de resposta do aplicativo mais lento.
  • Em um cluster de JVMs, o conteúdo será armazenado em cache de forma redundante em cada JVM, tornando ineficiente o uso do espaço de cache disponível.
  • Uma JVM recém-iniciada tem que preencher o seu cache, causando tempos de resposta iniciais lentos e carregamento alto na fonte de conteúdo do backend enquanto o cache se aquece.
Figura 1. Topologia tradicional do dynacache
Topologia tradicional do dynacache

A transferência do conteúdo em cache do servidor de aplicativos para uma grade de dados resolve todos esses problemas (Figura 2):

  • O tamanho total do cache pode escalar de forma elástica por meio dos recursos oferecidos pelo WebSphere eXtreme Scale e, ao mesmo tempo, continuar totalmente independente do heap da JVM do servidor de aplicativos ou das limitações do hardware do servidor.
  • O conteúdo em cache não é armazenado na JVM do servidor de aplicativos e, portanto, não contribui para o carregamento da coleta de lixo.
  • O conteúdo em cache é compartilhado entre servidores de aplicativos, ou seja, cada item só é armazenado em cache uma vez, e os servidores recém-iniciados têm acesso imediato aos itens anteriormente armazenados em cache por outros servidores, em vez de ter que buscar de forma independente uma cópia na fonte de conteúdo do backend.
Figura 2. Topologia de dynacache do WebSphere eXtreme Scale
Topologia de dynacache do WebSphere eXtreme Scale

Tanto o WebSphere eXtreme Scale quanto o dispositivo XC10 fornecem suporte integrado para transferir o conteúdo do dynacache para uma grade de dados. Para isso, é necessário apenas instalar o cliente do WebSphere eXtreme Scale na instância do WebSphere Application Server e configurar a instância do dynacache a ser transferida. Essa configuração oferece várias vantagens. Por exemplo, caches que podem ser muito maiores que o heap do servidor de aplicativos suportaria sem pagar o preço de armazenar em disco, também que são compartilhados entre instâncias do servidor de aplicativos e o conteúdo em cache que pode sobreviver a uma reinicialização do servidor de aplicativos.

O restante deste artigo descreve um conjunto de testes de desempenho executados pelos autores. Os testes serviram para determinar os benefícios do uso desse mecanismo para transferir a instância do dynacache do cache avançado do Web Content Manager para uma grade de dados implementada em dois dispositivos XC10.


Cenário de referência

Para a atividade de referência nesta série de testes, implementamos um cluster estático horizontal do WebSphere Portal com dois nós e um servidor HTTP IBM. Os modelos de wiki de fábrica foram usados para preencher seis bibliotecas de conteúdo da web, totalizando 50 GB de conteúdo em um banco de dados. Cada item de conteúdo de wiki inclui texto e imagens. Havia seis páginas do WebSphere Portal, e cada uma tinha um portlet de visualizador de conteúdo da web que renderizou uma wiki a partir de uma biblioteca de conteúdo da web. O portlet de wiki de fábrica exibiu uma lista de dez itens de conteúdo da wiki, por título, em cada vez. Como cada wiki tem milhares de itens de wiki, há mais de 1000 páginas de lista que os usuários podem visualizar.

Para fazer o teste, cada usuário:

  1. Efetua logon no WebSphere Portal.
  2. Navega aleatoriamente para uma das seis páginas de portal que renderizam wikis.
  3. Acessa aleatoriamente uma página de lista e visualiza todos os itens de wiki na página, clicando no link do conteúdo de wiki.
  4. Repete as etapas 2 e 3 dez vezes.
  5. Efetua logout.

Há dez segundos de "tempo para pensar" entre as ações do usuário. As duas transações do usuário que interessam são: acessar uma página de lista e visualizar um item de wiki.

Testamos três configurações de cache em relação ao Web Content Manager:

  1. No primeiro cenário, usamos o cache básico do Web Content Manager, no qual o portlet de renderização não obtém os benefícios do cache. Isso representa uma situação em que o heap do servidor de aplicativos é insuficiente para utilizar o cache avançado.
  2. No segundo cenário, ativamos o cache avançado e o ajustamos para o tamanho máximo com base no carregamento do usuário e o limite do heap da JVM, que é de 4 GB. O resultado disso foi um cache de 5000 entradas em cada JVM do WebSphere Portal por cache avançado do Web Content Manager.
  3. Para o cenário do dynacache transferido, usamos dois dispositivos de armazenamento em cache XC10 configurados em um coletivo para armazenar o conteúdo em cache com, no máximo, um milhão de entradas de cache.
Figura 3. Diagrama de topologia, incluindo os XC10s
Diagrama de topologia, incluindo os XC10s

Para transferir o cache avançado do Web Content Manager, a instância específica do dynacache (o cache de “processamento”) foi configurada para usar o provedor de dynacache do WebSphere eXtreme Scale e não o provedor padrão. Em seguida, a configuração foi apontada na grade de dados hospedada no coletivo do XC10. Observe que o tamanho do cache indicado, 12000, tem como resultado um tamanho total do cache de aproximadamente um milhão de entradas, devido à forma como o WebSphere eXtreme Scale implementa o cache ao longo das partições da grade de dados (Figura 4).

Figura 4. Configuração da instância do dynacache
Configuração da instância do dynacache

Usamos a referência pra executar dois casos de uso:

  • No primeiro caso, deixamos os sistemas aquecendo durante duas horas. Em seguida, o rendimento e o tempo de resposta foram medidos durante quatro hora e uma execução de carregamento de 300 usuários. Dessa forma, foi possível observar os benefícios de um grande cache de grade de dados, em comparação à ausência de cache ou até mesmo a um pequeno cache local.
  • No segundo caso, simulamos um cold start, ao iniciar os servidores e, em seguida, aplicar carga imediatamente e medir o rendimento e o tempo de resposta durante os 30 primeiros minutos do carregamento. Assim, obtivemos uma percepção sobre o impacto de colocar um novo servidor online ou reiniciar um servidor devido à manutenção.

Resultados da referência

Estado estável

No cenário do estado estável, vários benefícios tangíveis ao usar um grande cache transferido (Figura 5) foram observados. O rendimento (solicitações por segundo) aumentou 15% com a ativação do cache avançado e mais 25% quando o cache avançado do Web Content Manager foi transferido para o XC10. Em comparação com o cenário de cache básico do Web Content Manager, o rendimento aumentou 44% com o XC10.

Figura 5. Comparação do rendimento no estado estável (quanto mais alto, melhor)
Comparação do rendimento no estado estável (quanto mais alto, melhor)

O tempo de resposta para ir para uma página de lista diminuiu 13% com o cache avançado e 35% com o XC10 (Figura 6). O tempo de resposta para exibir o conteúdo da wiki diminuiu 20% com o cache avançado e 78% com o XC10 (Figura 7). A grande melhoria do tempo de resposta ao exibir conteúdo da wiki com o XC10 é o benefício da grande capacidade da grade de dados. Ao usar a implementação padrão do dynacache, houve muitos descartes do cache devido à limitação do tamanho do cache pelo heap da JVM.

Figura 6. Comparação do tempo de resposta no estado estável para acessar uma página de lista (quanto mais baixo, melhor)
Comparação do tempo de resposta no estado estável para acessar uma página de lista (quanto mais baixo, melhor)
Figura 7. Comparação do tempo de resposta no estado estável para exibir conteúdo da wiki (quanto mais baixo, melhor)
Comparação do tempo de resposta no estado estável para exibir conteúdo da wiki (quanto mais baixo, melhor)

Além disso, observamos uma diminuição de 35% nas conexões ativas com o banco de dados ao usar o XC10. Isso é esperado, já que foi fornecido mais conteúdo do cache do XC10, em vez de ser recuperado do banco de dados do Web Content Manager. Uma melhoria significativa no carregamento da coleta de lixo ao transferir o cache também foi observada. O período de tempo empregado para realizar a coleta de lixo diminuiu 71% em comparação à configuração padrão do cache com o cache transferido. Isso pode ser atribuído ao fato de se possuir menos objetos criados e destruídos no heap do servidor de aplicativos quando o conteúdo do cache é transferido.

Cold start

Para o cenário de cold start, somente o cache local avançado e o cache transferido avançado foram testados. O motivo disso é que um servidor sem cache ativado tem um desempenho aproximadamente igual antes e depois do período de aquecimento, já que não há cache para aquecer. O propósito desse teste foi demonstrar a importância de se ter o cache compartilhado pré-preenchido e disponível para um servidor de aplicativos recém-iniciado. Isso evita o período inicial de aquecimento durante o qual um servidor recém-iniciado terá tempos de resposta ruins e acionará uma carga alta contra a fonte de conteúdo do backend, já que ele recupera o conteúdo para preencher o seu cache. Com o cache transferido para uma grade de dados, ele pode ser mantido independentemente da reinicialização de qualquer servidor de aplicativos, ou até mesmo da reinicialização do cluster inteiro de servidores de aplicativos. Isso significa que, para desligar um servidor para manutenção ou incluir um novo servidor para manipular um aumento na carga, não é mais necessário aquecer cuidadosamente o cache do servidor depois da inicialização e antes de colocá-lo online novamente para uso na produção.

Assim como no cenário do estado estável, observamos benefícios significativos no rendimento e no tempo de resposta ao testar o desempenho do cold start. O rendimento melhorou 54% (Figura 8). O tempo de resposta para ir para uma página de lista diminuiu 26% (Figura 9) e o tempo de resposta para exibir uma página de wiki diminuiu 49% (Figura 10).

Figura 8. Comparação do rendimento no cold start (quanto mais alto, melhor)
Comparação do rendimento no cold start (quanto mais alto, melhor)
Figura 9. Comparação do tempo de resposta no cold start para acessar uma página de lista (quanto mais baixo, melhor)
Comparação do tempo de resposta no cold start para acessar uma página de lista (quanto mais baixo, melhor)
Figura 10. Comparação do tempo de resposta no cold start para exibir conteúdo da wiki (quanto mais baixo, melhor)
Comparação do tempo de resposta no cold start para exibir conteúdo da wiki (quanto mais baixo, melhor)

Conclusão

Com algumas mudanças simples na configuração e com a implementação do dispositivo de armazenamento em cache WebSphere DataPower XC10, foi possível melhorar significativamente a experiência do usuário final do IBM Web Content Manager e do WebSphere Portal. Foi verificado um tamanho máximo do conteúdo em cache de 9 GB nos nossos XC10s. Isso representa uma pequena parte da capacidade disponível de 480 GB fornecido por um coletivo de dois XC10s, mas é muito mais do que aquilo que poderia ser armazenado em cache pela JVM de um servidor de aplicativos individual usando o espaço de heap local.

Embora as operações de cache individuais sejam, por si mesmas, ligeiramente mais baixas devido à necessidade de acesso a rede, esse custo é mais do que compensado pela capacidade de aumentar significativamente a taxa de acertos do cache obtida por meio de um cache maior. Também é compensado aofazer com que uma perda de acerto no cache em um servidor de aplicativos tenha como resultado o pré-carregamento do cache para o próximo servidor de aplicativos que precisar do item.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Lotus, WebSphere
ArticleID=824883
ArticleTitle=Inovações dentro do alcance: Usando o WebSphere eXtreme Scale para Aprimorar o Desempenho do WebSphere Portal e do IBM Web Content Manager
publish-date=07162012