Introdução ao cache no Lumis Portal

Objetivos

• Apresentar conceitualmente os mecanismos de cache existentes no Lumis Portal.
• Prover as informações necessárias para a arquitetura, configuração e manutenção relacionadas aos diferentes tipos de cache do Lumis Portal.

Referências complementares

• Geração de páginas em cache
• Customização do mecanismo de limpeza de páginas em cache
• Observers
• Publicação seletiva de conteúdo no Lumis Portal
• XSL no Lumis Portal

Razões para utilizar cache

Cache é um mecanismo que armazena dados de forma transparente, para que futuras solicitações a esses dados se realize de forma mais rápida.

Essa maior rapidez no acesso aos dados pode se dar usualmente de duas formas, armazenando o mesmo dado em um meio de acesso mais rápido (por exemplo armazenando uma informação de memória ao invés de precisar consultar o banco de dados para obtê-la) ou então armazenando o resultado de um processamento necessário para se chegar a uma informação, de modo que no segundo acesso o processamento não precisa ser novamente executado (por exemplo armazenando fisicamente o HTML de uma página que da primeira vez precisou ser calculada dinamicamente). De uma forma ou de outra, a utilização de cache pode ser vista como a criação de uma redundância para obtenção de uma mesma informação.

Quando tratamos o cache de componentes dinâmicos, que possam variar o seu estado, é fundamental que seja contemplado um mecanismo de expiração do cache para manter a natureza dinâmica do componente. Por exemplo, se armazenamos em memória uma informação que normalmente seria obtida do banco de dados, é importante que qualquer processo que modifique essa informação dispare também algum mecanismo que remova essa informação da memória, de modo que no próximo acesso a ela seja necessário novamente obtê-la do banco de dados com seu novo valor, sendo colocada novamente em cache nesse momento.

Mecanismos de geração e expiração de cache podem variar muito dependendo do tipo de informação que se deseja armazenar e dos requisitos do sistema. Em determinados cenários pode ser que o mais importante seja que a informação seja sempre obtida do cache, ainda que esteja desatualizada e em processo de regeração. Em outros pode ser que o fundamental seja que a informação disponibilizada esteja atualizada sempre. A arquitetura da solução é que deve dizer qual abordagem seguir em cada caso.

A utilização de cache está relacionada ao desempenho da aplicação, portanto essa técnica deve ser aplicada com o único objetivo de melhorar o desempenho da aplicação como um todo e evitar problemas de performance. Sendo assim a definição de como será utilizado o cache em uma aplicação deve fazer parte de uma arquitetura consciente que avalie o custo e benefício em cada caso. O uso indiscriminado de cache pode levar a outros problemas, como o aumento de memória utilizada, o que pode levar a uma perda de performance da aplicação como um todo.

Os maiores candidatos a serem cacheados são objetos que são muito acessados, compartilhado por vários processos, e com alto custo de construção. O alto custo de construção pode estar relacionado a custo de CPU (numerosas operações para recalcular os valores do objeto), ou podem estar relacionada a custos de IO, quando os dados para recriar o objeto demandam custosas operações de IO (os dados estão num banco de dados ou em um web service). Quando o objeto não é compartilhado por vários processos, outras técnicas podem ser usadas, normalmente se utiliza uma referência ao objeto; exemplo de objetos compartilhados por vários processos são as configurações do sistema.

http://en.wikipedia.org/wiki/Cache

Uma consideração a ser feita na utilização de cache é a disponibilidade do recurso utilizado para armazenamento, seja ele memória, espaço em HD ou qualquer outro. Quanto maior o cache mais objetos podem ser armazenados e, portanto, maior a chance de se encontrar o objeto desejado em cache. No entanto, caches demasidamente grandes podem exaurir os recursos do sistema tornando-o capaz de processar menos solicitações ao mesmo tempo, ou até gerando situações de falta de memória (out of memory - OOM).

O Lumis usa e disponibiliza diversos tipos de cache.

• Cache de interface = Armazena em memória o HTML gerado para uma instância de interface.
• Cache de XSL = Armazena em memória o conteúdo dos arquivos XSL usados para transformação.
• Cache de objetos do Portal (PortalCache) = Armazena em memória diversos tipos de objetos do Portal, como definições de canais e páginas.
• Cache de página = Armazena em HD arquivos físicos .html com o resultado do HTML calculado para uma página.

Cache de interface

A classe ServiceInterfaceInstanceManager mantém cache dos HTMLs que são gerados na renderização das interfaces. O HTML é guardado em cache quando a instância de interface do serviço estiver configurada para usar cache, caso contrário o HTML gerado é descartado e será sempre recalculado quando houver necessidade de renderizar a interface. Dependendo da complexidade da interface gerar o HTML pode ter um custo elevado, quanto maior o custo de montar o HTML maior o benefício do cache. Abaixo a definição do objeto PortalCache utilizado para armazenamento do cache de instância de interface.

private PortalCache<Map<Locale, String>> serviceInterfaceInstanceHtmlCache = new PortalCache<Map<Locale, String>>("lumis.portal.serviceinterfaceinstance.ServiceInterfaceInstanceConfig.html", new InterfaceHtmlCacheDataProvider());

Como o HTML é guardado em memória, este deve ser igual sempre para toda requisição, caso contrário haverá inconsistência na apresentação da página. Em outras palavras, se o HTML de uma interface variar de requisição a requisição, por exemplo exibindo alguma informação que varie dependendo do usuário, esta não deve utilizar cache. Qualquer renderização que dependa de parâmetros do request não deve ter o HTML salvo em cache. É importante entender que o cache de uma interface é o HTML fruto da renderização de tal interface e que se o HTML for dinâmico não faz sentido mantê-lo em cache.

O Lumis Portal possui um mecanismo de expiração de cache de interface baseado em eventos que são lançados após a publicação, permitindo que interfaces que exibam conteúdos publicados dinamicamente possam ser colocadas em cache, o qual é expirado sempre que ocorre uma publicação que pode afetar o conteúdo HTML da interface em questão.

Por exemplo, uma interface de lista de notícias. Caso as notícias exibidas na lista sejam as mesmas, independente do usuário que esteja acessando (isto é, se não houver publicação customizada para usuários e grupos) ou de qualquer outro critério, ela pode ser configurada para ser utilizado cache, ainda que a publicação seja dinâmica. Ao publicarmos uma nova notícia que deva aparecer nessa lista é lançado um evento que é identificado pelo mecanismo de expiração de cache, removendo da memória o cache dessa interface. No próximo acesso a ela será gerado novo cache, de modo que apenas o primeiro acesso após a limpeza precisou ser dinâmico, os demais já irão usufruir das melhorias de performance relacionadas ao uso do cache.

O mecanismo de expiração de cache do Lumis Portal já contempla a utilização de critérios de publicação relacionados ao período. Por exemplo, no caso de uma notícia programada para entrar no ar em uma determinada data, quando esse momento chegar será também lançado um evento que cause a expiração do cache das interfaces onde essa notícia deve aparecer, como se ela estivesse sendo publicada nesse momento.

Sempre é possível, para os casos em que o cache de interface padrão não seja aplicável, a implementação de mecanismos diferentes de cache em serviços customizados. Por exemplo, se precisamos que a interface de menu esteja em cache mas ela precise variar dependendo do usuário autenticado, podemos criar um mecanismo que armazene diversas versões da interface, uma para cada usuário que a acessa, ao invés de apenas um cache. Esse tipo de implementação de cache, no entanto, precisa ser todo implementado no escopo do serviço customizado, não sendo um mecanismo nativo do Lumis Portal.

Configurando o cache de uma instância de interface

Nas propriedades da instância de interface, acessadas a partir do item “Propriedades” do menu de right-click sobre a interface, na aba Desempenho, pode-se definir se o cache está habilitado. São três opções:

• Não – o cache é desabilitado;
• Sim – o cache é desabilitado;
• Default – O valor default do serviço é usado;

O valor default normalmente é false, mas isso pode ser alterado na definição da interface de serviço (servicedefinition.xml).

No servicedefinition.xml pode-se configurar os valores default dos parâmetros de cache de acordo com o servicedefinition.xsd:

    
<xsd:complexType name="interface">
  <xsd:all>
  <xsd:element name="description" type="xsd:string" minOccurs="0"/>
  .....
  <xsd:element name="cache" type="cache" minOccurs="0" />
  .....
</xsd:complexType>



<xsd:complexType name="cache" >
  <xsd:sequence maxOccurs="unbounded">
    <xsd:element name="level" type="cacheLevelTypes" minOccurs="0" />
    <xsd:element name="personalization" type="cachePersonalizationTypes" minOccurs="0" />
    <xsd:element name="serverSideInclude" type="xsd:boolean" minOccurs="0" default="false"/>
  </xsd:sequence>
  <xsd:attribute name="enable" type="xsd:boolean" use="required"/>
</xsd:complexType>
    
  

Outra configuração do cache de interface é se este é a nível local ou de template. Instâncias de interface de um template de página configuradas para utilizar cache no nível do template farão com que todas as instâncias de interface correspondentes nas páginas criadas a partir desse template de página compartilhem o mesmo cache.

A vantagem de utilização do cache de interface no nível de template é a economia de memória utilizada, já que será gerado apenas um cache e compartilhado com todas instâncias de interface criadas a partir de uma mesma instância de interface do template. A restrição é que o HTML gerado para todas essas instâncias de interface deve ser igual, independente da página em que a interface se encontre.

Um exemplo típico de interface na qual pode ser utilizada essa configuração é a interface que exiba o logotipo do Portal. Como ele é o mesmo em todas as páginas não faz sentido diversas vezes o mesmo trecho HTML em memória. Por outro lado, um exemplo típico em que não podemos utilizar essa configuração é na interface de caminho da página. Embora seja uma interface que tipicamente fica no template de página, como ela varia de página para página criada a partir desse template não podemos configurar o seu cache para ser armazenado no nível do template de página.

Quando se usa nível local é gerado um cache para cada instância de interface, neste caso se a interface tiver sido definida em um template existirá um cache para cada página onde o template tiver sido aplicado.

Mesmo que a interface não tenha sido definida em um template é possível configurá-la com nível de template, contudo será tratada como local.

O nível de cache default em geral é local, mas isso pode ser alterado na definição da interface (servicedefinition.xml), da mesma forma como fora explicado anteriormente para o default de cache habilitado/desabilitado.

Cache de XSL

Quando o cache está habilitado (default), o conteúdo dos arquivos XSL que o sistema usa são armazenados em memória, de forma que o próximo acesso ao XSL não precisa carregá-lo do disco.

Cada XSL que for usado pela primeira vez tem sua configuração armazenada no banco de dados, para permitir a administração do seu cache. A configuração basicamente consiste de informações do nome do arquivo e se o XSL tem o cache habilitado ou desabilitado.

Existem algumas formas de se expirar o cache de um arquivo XSL. A primeira delas é através da interface de edição de estilos, acessada a partir do item de menu “Estilo” do menu de right-click sobre uma interface. Essa interface está representada abaixo:

Editar e salvar um XSL através dessa interface irá expirar o seu cache para contemplar as alterações realizadas. Além disso, também é possível utilizar o botão “Limpar Cache” para explicitamente limpar o cache desse arquivo sem realizar nenhuma mudança.

Além disso, explicitamente limpar o cache de uma página ou canal também irá limpar o cache das instâncias de interface dessa página (ou das páginas desse canal) assim como o cache dos XSL’s utilizados nessas instâncias de interface.

Por último também é possível limpar o cache de um XSL através do Gerenciador de Cache de XSL. Essa interface é acessada a partir do menu Configuração – Gerenciadores de Cache – Cache de XSL e está representada abaixo:

Nessa interface é exibida a lista dos arquivos XSL que já foram acessados e, portanto, colocados em cache e armazenados no banco de dados. Através dela é possível verificar os XSL’s que tem configurações gravadas no banco, confirmando para cada um se o arquivo está com o cache habilitado e se o seu conteúdo está em cache nesse momento. Além disso também é possível habilitar um cache XSL que tenha sido previamente desabilitado, desabilitar o cache de um XSL, limpar o cache de um XSL, e excluir o cache de um XSL.

A diferença de limpar e excluir um cache é que limpar apenas remove o XSL de memória, enquanto excluir além de remover o XSL de memória remove a configuração de tal cache do banco de dados. Em ambos os casos se o XSL for utilizado novamente este voltará a ser carregado em memória e a configuração será recriada no banco caso esta tenha sido removida. A opção excluir serve na prática para remover configurações de XSLs que não estejam mais em uso no sistema.

Cache de XSL em ambientes clusterizados

A interface de administração do cache de XSL representa o estado do cache de um nó do cluster. Diferentes nós do cluster podem ter em memória XSLs diferentes. Por exemplo: se uma interface tiver sido renderizada em apenas um dos nós do cluster, apenas esse nó terá o XSL usado por essa interface carregado em cache. Num ambiente clusterizado não se deve verificar o estado do cache XSL através do balancer, deve-se verificar nó a nó diretamente.

As modificações realizadas pela interface administrativa referentes à cache XSL não são replicadas pelo cluster.

Na interface de administração de cache XSL são mostrados apenas os XSL’s que tiverem configuração gravada no banco de dados. Caso o XSL esteja carregado mas a sua configuração tenha sido removida, este não aparecerá na interface mesmo que o cache esteja carregado em memória. Tal situação pode ocorrer caso o XSL esteja em memória e o registro tenha sido apagado através de outro nó do cluster.

Cache de XSL em ambientes de desenvolvimento

É recomendável que o cache de XSL seja desabilitado em ambientes de desenvolvimento, já que a alteração de um arquivo XSL através do acesso direto ao arquivo não expira o seu cache (essa expiração só ocorre se a alteração foi realizada através da interface de edição de estilos). Essa medida tem o objetivo de facilitar o desenvolvimento evitando a necessidade de limpeza explícita do cache do XSL para que as alterações realizadas no arquivo sejam aplicadas no ambiente.

É importante frisar que é fundamental que toda e qualquer alteração no conteúdo de XSL’s ocorra apenas em ambiente de desenvolvimento, nunca em produção. Não só pelo fato de que alterações nos XSL’s não são replicadas automaticamente entre os membros do cluster mas também para evitar a geração de problemas em produção causados pela falta de testes sobre as alterações realizadas.

Cache de objetos do Portal (PortalCache)

O Lumis utiliza cache de objetos para melhorar o desempenho do sistema. Objetos que são muito acessados podem ser armazenados em memória para tornar mais rápido obter uma referência a tal objeto.

Alguns exemplos de objetos que são armazenados são: definições de canais, de páginas, de grupos, de usuários, de controle de acesso, entre muitos outros. Como na maior parte dos tipos de cache, esses objetos também podem sofrer alterações através da administração do Portal.

Por exemplo, no caso de um canal. Na primeira vez que é visualizada a interface de propriedades de um canal específico suas informações são obtidas do banco de dados e armazenadas em cache. A partir daí, sempre que for necessário obter essas informações elas serão obtidas da memória.

No entanto, as informações de um canal podem ser alteradas a partir da própria interface de propriedades ou através de outras operações realizadas sobre o canal. Nesses casos também são disparados processos para expirar o seu cache, de modo que nunca sejam obtidas informações desatualizadas do cache de um canal. Esse mesmo princípio é válido para os demais objetos que podem ser armazenados no cache do Portal.

Existe uma interface administrativa para os caches do portal, que pode ser acessada através do menu Configuração -> Gerenciadores de Cache -> Caches do Portal. Essa interface está representada abaixo:

Nessa interface é possível, para cada objeto que pode ser colocado em cache pelo Portal, visualizar:

• A capacidade configurada para o seu cache.
• O tamanho do cache (ou o quanto da capacidade total está ocupado).
• O número e percentual de tentativas de acesso a objetos no cache bem sucedidas (“Acertos”).
• O número e percentual de tentativas de acesso que não foram bem sucedidas (“Falhas”).

Nessa interface também é possível limpar o cache de um determinado tipo de objeto, o que remove todos os objetos armazenados neste, ou seja, o valor de “Tamanho” é zerado. Também é possível limpar as estatísticas de acertos e falhas de acesso a um determinado cache, cujas aplicações veremos mais a seguir.

A única propriedade que pode ser alterada a partir dessa interface, utilizando o botão “Editar”, é a capacidade para um determinado tipo de cache. A alteração é realizada através da interface ilustrada abaixo:

O cache de cada objeto é criado com determinada capacidade default, especificada no lumisportalconfig.xml pela tag:

    
<cache>
  <defaultCapacity>1000</defaultCapacity>
  <overflowType>soft</overflowType>
</cache>
    
  

Caso o lumisportalconfig.xml não defina o valor default, o sistema assumirá o valor 1000 como default.

    
Classe PortalContext :
private static int cacheDefaultCapacity = 1000;
...
cacheDefaultCapacity = XmlUtil.readNodeInt("/portalConfig/cache/defaultCapacity", profileDom, cacheDefaultCapacity);
    
  

No banco de dados existe uma tabela que armazena as configurações dos caches do portal que tenham sido customizados: lum_cache.

lum_cache no Oracle:

Quando a capacidade do cache de um objeto é alterado pela interface acima, é criado um registro na tabela lum_cache. Na interface aparece um asterisco na coluna “Capacidade (atual)” sinalizando que o valor fora customizado:

Para voltar a usar o valor default do sistema basta selecionar o cache e clicar no botão “Usar Padrão”.

O valor da capacity de cada cache pode ser alterado programaticamente pelo método da classe PortalCache:

public void setCapacity(int newCapacity)

O valor default de capacity é determinado na criação do cache. O método setCapacity é invocado após a criação do cache, portanto quando a capacity é determinada programaticamente irá sobrepor o valor default, isso quer dizer que mesmo que se defina no banco (ou pela interface de administração) um valor default este será sempre sobreposto caso se escolha definir a capacity programaticamente. Em outras palavras, quando o valor da capacity for definido programaticamente, este poderá ser alterado pela interface de administração, contudo o valor será perdido após um restart, pois neste ponto o valor será novamente determinado pelo método setCapacity.

Sempre que possível o valor de capacity deve ser definido pela interface administrativa ao invés de programaticamente.

A classe PortalCache tem outro atributo que pode ser alterado programaticamente, maxAgeSeconds. Seu valor default não define tempo máximo:

    
public static final int MAX_AGE_INFINITE = -1;
    

Esse atributo define o tempo máximo que um objeto pode ser mantido em memória, o que é útil no caso de objetos que devem ser alterados em runtime. Desta forma pode-se forçar que o valor seja recalculado de tempos em tempos.

É possível configurar um segundo nível de cache. O segundo nível representa uma extensão do espaço definido para o primeiro nível do cache, que pode ser utilizado dependendo da disponibilidade dos recursos de memória do sistema. A forma como esse segundo nível será preservado quando o sistema se deparar com a necessidade de utilizar recursos de memória que estejam sendo usados no segundo nível de cache pode ser configurada. Essa configuração é feita no lumisPortalConfig.xml na tag:

    
<overflowType>soft</overflowType>
    
  

Existem três configurações válidas para o segundo nível de cache: none, soft, weak. O valor default é soft:

    
Classe PortalContext:
private static String cacheOverflowType = "soft";

cacheOverflowType = XmlUtil.readNodeString("/portalConfig/cache/overflowType", profileDom, cacheOverflowType);
    
  

Para desabilitar o segundo nível de cache deve-se usar o valor “none”. Para usar soft references usar o valor “soft” (default), ou para usar weak references usar o valor “weak”. Este atributo não pode ser alterado programaticamente.

Estatísticas do PortalCache

Cada objeto PortalCache está associado a estatísticas de acesso desse cache:

As estatísticas têm informações sobre acertos e falhas. Um acerto corresponde a uma busca de um objeto no cache e o objeto estava disponível, uma falha significa que uma busca fora realizada, mas o objeto não estava disponível no cache e, portanto, precisou ser obtido do banco de dados, momento no qual ele é então colocado em cache. Estas informações podem servir para realizar um ajuste fino na aplicação. Um número grande de falhas pode sinalizar que o cache está pequeno para aquele tipo de objeto, sendo recomendado o aumento da capacity de tal cache.

Quando o sistema é iniciado o cache está vazio e, portanto, o número de falhas tende a ser maior durante o startup do sistema, após um tempo em serviço a maioria dos objetos já devem estar carregados. Para fazer um ajuste fino do tamanho do cache é recomendado que após um período de uso do sistema as estatísticas sejam limpas e só então passe a se fazer medições. Esse tipo de ajuste é importante para que se defina um tamanho que não seja desnecessariamente grande e, portanto, ocupe muita memória do sistema e que não seja muito pequeno a ponto de termos um número muito grande de falhas, o que significa que não estamos de fato otimizando o acesso àquele tipo de objeto.

Cache de página

Uma forte característica do Lumis é a possibilidade de manter as páginas que são geradas em cache. Este muitas vezes é chamado de cache HTML, mas como outros caches também guardam HTMLs o mais correto é chamar de Cache de Páginas.

O processo de renderização de uma página normalmente significa capturar as informações necessárias para a renderização dos componentes da página e processar essas informações gerando no output um HTML, o mecanismo de cache salva em disco o HTML gerado. Nas próximas solicitações o HTML salvo em disco é servido ao invés de ter que processar todas as informações novamente.

Quando a URL possui parâmetros, é gerado um arquivo HTML para cada combinação de parâmetros. Por exemplo, se uma página de detalhes recebe como parâmetro o ID da notícia, será gerado um HTML da página de detalhes para cada notícia.

Para uma página utilizar cache de página, é preciso que essa configuração seja realizada no campo “Gerar arquivo HTML” na aba “Geral” das propriedades da página, conforme vemos na interface abaixo:

As opções de configuração desse campo são:

• Herdar configuração = Herda a configuração desse campo especificada no canal que contém essa página.
• Não = Não utiliza cache de página.
• Utilizar para todos os usuários = Gera o cache de página e serve esse cache qualquer que seja o usuário requisitando a página.
• Utilizar apenas para usuário guest = Gera o cache de página mas só serve esse cache para o usuário guest. Para usuários autenticados responde a página dinâmica. O objetivo dessa configuração é atender aos casos em que a página é igual apenas para usuários não autenticados, e nesse caso pode utilizar cache por razões de desempenho, mas precisa ser dinâmica para usuários autenticados.

Quando uma página está configurada para herdar a configuração do canal, o que quer que esteja configurado no canal que contém essa página será aplicado à página. Para realizar essa configuração no canal, é preciso acessar sua interface de Propriedades, na aba “Páginas”, campo “Gerar arquivo HTML”, conforme imagem abaixo:

A configuração desse campo nas propriedades do canal tem o objetivo puramente de permitir realizar a configuração uma vez só, de modo que essa configuração seja automaticamente aplicada a todas as páginas que estejam contidas nesse canal e estejam configuradas para herdar a configuração.

Repare que as opções desse campo nas propriedades do canal são as mesmas das propriedades da página, ou seja, também é possível configurar um canal para herdar a configuração. Nesse caso, ele herdará do seu canal pai, e assim recursivamente.

Como a opção “Herdar configuração” é default para todos canais e páginas criados, esse mecanismo de herança é útil para facilmente, com apenas uma configuração, habilitarmos a geração de cache de página de toda uma área do Portal ou mesmo do Portal inteiro, se essa configuração for realizada no canal raiz da estrutura.

A utilização do cache de página não elimina a necessidade de utilização de cache de interface nas interfaces da página em questão. Uma página que esteja com suas interfaces adequadamente configuradas no que diz respeito ao cache de interface terá o cache de página gerado mais rapidamente do que se não estivesse utilizando cache de interface.

Isso porque, no momento da geração do cache de página, é feita uma requisição normalmente para se obter o conteúdo HTML da página, antes desse conteúdo ser gravado em um arquivo físico. Se as interfaces dessa página estiverem em cache, essa requisição será mais rápida já que não será necessário calcular cada interface dinamicamente. A expiração do cache de uma página não significa que foi expirado o cache de todas as suas interfaces, sendo assim a diferença no tempo de regeração da página em cache pode ser significativa se tivermos esse cuidado.

Ou seja, uma arquitetura de cache apropriada para a definição da estrutura do Portal envolve necessariamente uma análise cuidadosa para aplicação desses dois tipos de cache em conjunto visando obter o melhor desempenho possível.

Como qualquer tipo de cache que envolva elementos que podem ter seu conteúdo alterado, o cache de página também possui o seu mecanismo de expiração para manter o cache sempre atualizado.

Tanto a publicação de conteúdo quanto alterações estruturais podem ser responsáveis por mudanças que afetem o conteúdo HTML de uma página. Nesses casos são lançados eventos específicos para cada caso, indicando que houve algum tipo de mudança que pode trazer a necessidade de regerar um determinado conjunto de páginas. Esses eventos são capturados pelo mecanismos de expiração de cache de página para limpar os arquivos desatualizados, que em seguida serão gerados novamente pelo gerador.

Mais informações sobre geração de páginas em cache podem ser obtidas no artigo “Geração de páginas em cache”, incluindo:

• O ciclo de geração de uma página.
• Como erros na geração influenciam o gerador de cache.
• Processamento da requisição de uma página em cache.
• Mecanismo de geração de páginas em cache.
• Mecanismo de expiração de páginas em cache.
• Shadow cache.
• Geração automática e sob demanda.
• Arquitetura e desenvolvimento com cache de página.

Principais pontos para abordagem prática

• Arquitetura e configuração de cache de interface e cache de página em um dado cenário.

• Ajuste fino das configurações relacionadas a cache de objetos do Portal

Autor: Pedro Torres (Lumis)