Estratégias de cache para uma solução usando Lumis Portal

Objetivos

Apresentar uma revisão da funcionalidade de cache (interfaces e páginas) no Lumis Portal.
Explicar as vantagens do uso de cache em portais.
Ilustrar casos típicos de interfaces e como colocá-las em cache.
Discorrer sobre formas de arquitetar páginas e interfaces de forma a usar cache.
Apresentar cenários típicos de portais e cuidados que devem ser observados.

Conhecimentos necessários

Estruturas de um portal em Lumis (serviços, canais, páginas, interfaces, instâncias de interface, instâncias de serviço).
Cache de interface, cache de página, gerador de páginas em cache HTML.

Conceituação

Um portal consiste de uma estrutura de canais e páginas, sendo cada uma destas páginas formada por uma quantidade de interfaces. O código-fonte final de cada página é obtido pela inclusão, no código que define a própria página, do HTML gerado por cada uma destas interfaces.

A figura a seguir mostra um arranjo de interfaces que poderia ser utilizado em uma página contendo uma lista de notícias.

Como em qualquer página do portal, cada interface é responsável por gerar o trecho de código que definirá visual e funcionalmente a área onde se encontra. Os trechos gerados serão ‘encaixados’ em pontos previamente definidos do código geral da página, complementando desta forma o que será enviado ao ‘browser’ e visualizado pelo usuário final.

Ao ser visualizada uma página, o Lumis Portal cuida de verificar se o usuário possui ou não permissão de acesso, não apenas à página mas a cada interface. Cada interface, ao ser renderizada, gera um acesso ao servidor de aplicação e, potencialmente, a um recurso externo (usualmente uma base de dados), gerando um HTML (ou uma estrutura de informações em XML que será, então, convertida para o código HTML adequado), finalmente disponibilizado para a montagem de toda a página.

Este processamento dinâmico é parte integrante de qualquer solução de portais, mas em muitas situações não precisaria ser repetido a cada visualização de página.

Suponha que, no exemplo apresentado, o ‘cabeçalho’ seja o mesmo para todos os usuários; a interface de ‘busca’ também é, potencialmente, a mesma (ainda que os resultados de busca possam variar dependendo das permissões do usuário e dos termos procurados). O mesmo acontece, potencialmente, para ‘login/senha’, ‘rodapé’ e ‘links’. Em diversos casos os menus podem variar dependendo do usuário (por permissão de acesso a algumas áreas dependendo de seu perfil), mas em portais internet usualmente são os mesmos, ao menos até que o usuário se autentique.

Se assumirmos também neste exemplo que tanto a ‘lista de notícias’ quanto os ‘produtos em destaque’ não são específicos por usuário, fica simples perceber que, a cada visualização, o HTML gerado tende a ser exatamente o mesmo, vindo a mudar apenas quando houver cadastro de uma nova notícia, link ou produto – ou no caso de alterações na camada visual ou na estrutura do Portal.

Para reduzir o acesso ao servidor de aplicação e, com isso, o tempo necessário para entrega de uma página requisitada, esta página poderia ser integralmente gerada em HTML. Este arquivo poderia ser disponibilizado diretamente por um servidor web, sem necessidade de qualquer processamento dinâmico de um servidor de aplicação. Neste cenário seria responsabilidade do Lumis Portal gerar novamente esta página sempre que algum conteúdo fosse inserido ou alterado, garantindo desta forma que as informações publicadas fossem apresentadas adequadamente.

Em outros casos, apenas partes de uma página (algumas interfaces) podem ter este comportamento. Isto aconteceria, neste mesmo exemplo, se cada usuário autenticado tivesse acesso a ‘produtos em destaque’ específicos para ele ou para seu perfil, ou de serem escolhidos aleatoriamente produtos a cada acesso entre os marcados como ‘destaque’. Neste caso, apenas as áreas (interfaces) que se repetem a cada acesso poderiam ter seu código previamente gerado, melhorando com isso a performance da página a partir da redução da necessidade de acesso ao servidor de aplicação.

O exemplo mostrado pode ser interpretado de diversas formas, dependendo do funcionamento esperado de cada interface. Um pleno conhecimento das características desejadas para publicação e exibição de informações em um portal é vital para que sejam determinadas as otimizações cabíveis.

A esta geração prévia de trechos de código (parcial ou de toda uma página) chamamos de ‘cache’. Para que seja possível planejar como configurar esta característica em seu portal é imprescindível um bom conhecimento das características de cache providas pelo Lumis Portal.

Formas básicas de cache

Este artigo tratará apenas do cache mantido pelo Lumis Portal, sendo importante apenas pontuar a existência de diversos outros níveis de cache entre a visualização do usuário e o portal. Uma página pode não ser requisitada ao servidor por estar no ‘cache’ interno do browser, por exemplo, ou de alguma estrutura de rede (por exemplo, um proxy de acesso). Outros níveis de cache podem ser também mantidos pela infraestrutura do provedor, reduzindo a sobrecarga no servidor web. Todas estas possibilidades são externas ao Lumis Portal, e independem da tecnologia de cache tratada neste texto.

O Lumis Portal permite que o cache seja estruturado de diversas formas, sendo as duas mais comuns mostradas a seguir.

Páginas da solução podem ser completamente colocadas em cache.
Interfaces podem ser colocadas em cache (permitindo desta forma a pré-geração de ‘partes’ das páginas que se repitam).

Pensando apenas nestas duas possibilidades, a definição do que colocar em cache é bastante simples; porém alguns portais com grande volume de acessos ou de atualizações podem precisar de mecanismos mais sofisticados que serão abordados em outras seções deste documento.

Limpeza de cache

Em um website construído sem o auxílio de uma ferramenta de gestão de conteúdo, o HTML de uma página precisa ser modificado sempre que qualquer informação nela contida seja inserida, alterada ou excluída. Um novo arquivo HTML substitui o anterior, que passa a conter a nova versão da página. Uma mesma alteração pode ser necessária em várias páginas – se o telefone da empresa estiver no rodapé de cada página, sua alteração pode resultar em novos HTMLs para todo o portal.

Esta mesma rotina é necessária nas páginas de um portal que estejam em cache. Quando uma informação é inserida, alterada ou excluída, cabe ao portal identificar que HTMLs devem ser expirados e gerados novamente. Sem que isso fosse feito, o portal continuaria a exibir as páginas anteriormente criadas, com informações desatualizadas.

Uma situação similar acontece quando há interfaces em cache, mesmo que a página seja gerada dinamicamente. Uma alteração das informações cadastradas no portal precisa determinar que interfaces em cache precisam ser expiradas e descartar os trechos HTML correspondentes.

Um conteúdo pode ser apresentado em diversas interfaces, de formas diferentes: a alteração do título de uma notícia altera tanto a interface de ‘lista de notícias’ quanto a própria página que a apresenta na íntegra. No caso de ser uma lista paginada de notícias, a inserção ou alteração de uma notícia deve expirar todas estas páginas. A mesma notícia pode aparecer sob a forma de ‘destaque’ em uma seção do portal ou até mesmo ser referenciada como ‘notícia relacionada’ de outra. Em outras palavras, uma alteração de conteúdo pode afetar um grande número de interfaces e páginas.

Ao mesmo tempo, esta expiração deve ser cuidadosamente realizada pelo Portal, evitando o descarte de mais interfaces que o necessário. A expiração não pode ser sensível apenas a que interfaces precisam ser expiradas, mas também a que conteúdo for alterado. Muitos serviços de conteúdo possuem uma interface de detalhes (onde, no caso de um serviço de notícias, é exibida sua ‘íntegra’); o portal não pode expirar arbitrariamente todas estas interfaces, pois apenas uma diz respeito à informação alterada.

Este mecanismo de detecção e expiração é chamado ‘limpeza de cache’. De uma forma geral, este processo é responsável por determinar, a cada informação alterada no portal, que interfaces serão ajustadas, e expirar seus caches. Páginas em cache que possuem interfaces nesta situação devem, também, ser expiradas.

Entretanto, a limpeza automática não atende a todas as situações. Mudanças estruturais do Portal podem, também, alterar a forma como uma página ou interface é apresentada.

Novas interfaces podem ser inseridas em uma página, ou mudanças no serviço (incluindo uma nova definição de sua camada visual) podem ser realizadas. Nestes casos o Lumis Portal precisa ser informado que o cache de algumas páginas ou canais precisará ser expirado, o que é feito diretamente na área administrativa. Esta tarefa não é foco deste trabalho por não ser parte da estratégia de planejamento de cache de uma solução, mas meramente uma tarefa administrativa que deve ser levada em conta para que a versão correta de uma página seja sempre apresentada. Maiores detalhes podem ser vistos na documentação do Lumis Portal.

Outro problema da limpeza automática de cache (e que, neste caso, nos é bastante importante) é a possibilidade de expiração de muitas páginas simultaneamente. Voltando à figura apresentada como exemplo, a parte central da página é uma interface de ‘lista de notícias’. Supondo que se trate de uma lista paginada em um portal com grande número de notícias cadastradas e alta taxa de alterações, cada notícia inserida, apagada ou alterada precisará expirar todas as páginas da lista, devido à acomodação dos itens (a última notícia de cada página passará a ser a primeira da página seguinte a cada novo conteúdo inserido). Supondo que este portal de exemplo possua cinco mil notícias, paginadas a cada dez itens, cada notícia inserida limpará o cache de mais de 500 páginas.

Outras situações podem levar à limpeza de mais interfaces ou páginas que o necessário. Formas de solucionar ou minimizar este problema serão tratadas a seguir, sendo importante neste momento, apenas, a percepção desta situação.

Geração automática ou sob demanda

Até o momento foram mencionadas as possibilidades de configurar páginas ou interfaces como estando em cache, e que o Lumis Portal se encarrega de expirar automaticamente páginas e interfaces quando identifica esta necessidade devido a alguma alteração de conteúdo.

A limpeza de cache garante apenas que a página expirada não será mais oferecida, apagando-a do sistema de arquivos e marcando-a como pendente de nova geração. O Lumis Portal oferece duas formas de gerar uma página com cache expirado:

Automaticamente, com uso de um gerador de cache em ‘background’ que se encarrega de produzir os arquivos e disponibilizá-los para consultas futuras.
Sob demanda, em que o arquivo é gerado quando a nova página é visualizada pela primeira vez.

Obviamente, cada abordagem tem suas vantagens. A geração automática pode sobrecarregar os servidores, pois páginas expiradas serão enfileiradas para geração, mesmo as que não seriam visualizadas imediatamente.

Em portais onde há grande manutenção de conteúdos é comum que muitas páginas sejam geradas diversas vezes sem que elas sejam requisitadas uma única vez naquele intervalo de tempo. Por outro lado, a geração sob demanda atrasa a entrega da página quando de seu primeiro acesso. Se um usuário requisita uma página expirada, terá de aguardar que esta seja gerada para visualizá-la. Apenas os próximos acessos serão beneficiados pela geração de cache.

A forma a ser usada para a geração de cache (automática ou sob demanda) é uma decisão que deve ser tomada durante a definição das estratégias de cache de um portal.

Priorização da geração automática

Quando a geração automática é configurada em uma solução, as páginas expiradas são inseridas em uma ‘fila’ aguardando que o gerador as processe. Em um portal com muitos conteúdos e grande índice de atualizações pode ser necessário interferir nesta fila, indicando que páginas são prioritárias.

O cálculo de prioridade leva diversas informações em consideração, sendo uma delas configurável em momento de montagem. Para maiores explicações refira-se ao manual do Lumis Portal.

Determinação de que páginas serão automaticamente expiradas

Uma página é gerada pelo Lumis Portal a partir de sua URL dinâmica, que contém o arquivo ‘main.jsp’ e os parâmetros que lhe são passados e que identificam unicamente uma página. Embora este identificador seja único, a forma de visualizar a mesma página (URL) pode variar por conta do usuário atual e suas permissões, ou de características de algum dos serviços (que pode, por exemplo, selecionar um conteúdo aleatoriamente de uma lista).

Os parâmetros que identificam a página podem variar bastante, passando não apenas informações do canal ou página desejados, mas outros específicos para uso das interfaces sendo exibidas. Parâmetros comumente utilizados incluem o identificador do conteúdo (para exibição de sua página de detalhes) e o número de ordem do primeiro item em uma lista paginada.

Cada página HTML criada pelo portal possui uma URL dinâmica, a mesma que seria utilizada para sua visualização sem cache.

O Lumis Portal assume, a partir das informações de expiração que lhe são enviadas (locale, identificador da página e parâmetros que identificam seu conteúdo), que páginas adicionais devem ser limpas.

Qualquer página que atenda às regras mostradas a seguir será expirada:

O identificador de página (lumPageId) e locale são os mesmos enviados no evento.
A página não possui nenhum dos parâmetros enviados, ou possui todos os parâmetros enviados com os mesmos valores do evento.

O exemplo ilustrativo a seguir foi extraído de um artigo sobre expiração de cache publicado originalmente no LINX (http://linx.lumis.com.br/linx/bc/java/expiring-html-cache.htm), apenas em língua inglesa. A discussão considera a lista de páginas mencionada a seguir, assumindo que todas estão com o mesmo ‘locale’ e em cache HTML.

main.jsp?lumPageId=Page1 – página contendo uma lista de conteúdos.
main.jsp?lumPageId=Page1&startAt=50 – segunda página da lista, iniciando no 50º elemento.
main.jsp?lumPageId=Page2&itemId=111 – página com detalhes do conteúdo de código 111.
main.jsp?lumPageId=Page2&itemId=222 – página com detalhes do conteúdo de código 222.
main.jsp?lumPageId=Page2&itemId=333 – página com detalhes do conteúdo de código 333.
main.jsp?lumPageId=Page2&itemId=444 – página com detalhes do conteúdo de código 444.

Os valores atribuídos aos prâmetros foram alterados para tornar o exemplo mais legível. Em uma situação real os identificadores de página e conteúdo seriam GUIDs, transformando a primeira URL em algo como ‘main.jsp?lumPageId=8A94A98E2120D3C60121213C9870097A’, por exemplo.

Uma alteração no conteúdo de número ‘333’ dispararia um evento de limpeza de cache para as páginas ‘Page1’ e ‘Page2’ (onde o Portal percebe que existem interfaces de lista e detalhes daquela mesma instância de serviço), com itemId ‘333’. Utilizando as regras mencionadas, as únicas páginas expiradas seriam as seguintes:

main.jsp?lumPageId=Page1 – identificador de página igual a um dos enviados, sem itemId.
main.jsp?lumPageId=Page1&startAt=50 – idem ao anterior.
main.jsp?lumPageId=Page2&itemId=333 – identificador de página igual, itemId igual.

Desta forma o Lumis Portal é capaz de expirar o cache das páginas de lista onde o conteúdo se encontra listado, e de sua página de detalhes. As páginas específicas dos demais conteúdos (suas páginas de detalhes) não seriam expiradas, e listas de conteúdos de outras instâncias do mesmo serviço (que teriam outros lumPageIds) não seriam afetadas.

Trata-se de um mecanismo simples e que resolve, na maior parte das vezes, a expiração de páginas. Entretanto, em alguns casos pode haver limpeza de mais páginas que o necessário, sobrecarregando o servidor ou atrasando a entrega de páginas recém-expiradas.

O Lumis Portal provê diversas formas de interferir nesta lógica, podendo inclusive informar exatamente que páginas ou interfaces devem ser expiradas em cada tipo de alteração.

Customizações de cache

Em alguns casos pode não ser desejável que o Lumis Portal tente inferir quais interfaces ou conteúdos terão seu cache expirado. Serviços de conteúdo criados no Lumis Portal utilizam-se automaticamente do mecanismo de identificação provido pelo portal rapidamente explicado na seção anterior, que podem ser customizados ou ignorados.

Várias formas de customização deste comportamento podem ser implementadas.

A notificação de alteração de dados que causa a expiração das interfaces e páginas pode ser completamente desativada na construção dos serviços com a inclusão de um elemento ‘<sendRenderDataChangedNotification>‘ com o valor ‘false’ na definição de seus process action handlers.

Ao utilizar este artifício, o Portal não será notificado de alterações nos conteúdos daquele serviço, e as interfaces nunca serão automaticamente expiradas. O serviço precisa, portanto, cuidar desta tarefa, verificando e expirando cada uma das interfaces que precisar. Tal abordagem, se necessária, deve ser executada cuidadosamente, pois pode causar efeitos colaterais desagradáveis.

Outras formas de alterar este comportamento padrão envolvem permitir que o serviço decida se a alteração deve ou não expirar cache (na verdade, se deve ou não gerar uma notificação para o Lumis Portal), especificar que interfaces devem ser expiradas, ou mesmo mencionar especificamente a expiração de páginas, instâncias de serviço ou de interfaces.

Para maiores detalhes sobre estas possibilidades verifique a documentação do produto e das APIs disponibilizadas, bem como artigos no LINX que tratam de ‘cache’, em especial a discussão sobre a limpeza automática de cache em serviços DOUI (http://linx.lumis.com.br/linx/comunidade/forum-java/e-possivel-configurar-um-servico-para-que-o-doui/content-nao-limpe-o-cache-automaticamente-.htm).

Em alguns casos o serviço precisará realmente determinar o que deve ser expirado. É comum a utilização de portais para aquisição de informações de bases externas, usualmente por meio de webservices ou importação de informações via ETL. Nestes casos não há como o Lumis Portal inferir que páginas ou interfaces devem ser expiradas, cabendo ao serviço determinar estas informações.

Planejamento de uma solução para bom uso de cache

Para garantir que um portal atenda seus requisitos de performance ou disponibilidade é vital que o recurso de cache HTML seja utilizado adequadamente. Um portal com grande parte de suas páginas em HTML garante seu funcionamento mesmo em caso de problemas com servidor de aplicação, ou durante tarefas de manutenção. O bom uso de cache otimiza também o investimento em infraestrutura e o tempo de carga das páginas.

Entretanto, para que um portal possa utilizar-se destes benefícios é importante que, durante seu levantamento, requisitos de cache sejam levados em consideração. A arquitetura do portal e dos serviços que o comporão também precisa ser feita com base nestes princípios. Portais existentes podem ser ajustados de forma a aproveitar melhor o cache provido pelo Lumis Portal, mas o esforço dedicado a esta alteração sempre será superior ao que seria necessário se alguns passos simples fossem considerados nos estágios iniciais do projeto.

Para compreender um pouco melhor o que significaria planejar antecipadamente todo um portal para utilizar cache, e as alterações necessárias, consideremos as decisões arquiteturais que podem influenciar o cache em uma única página de um portal. Para isso, retomaremos o exemplo inicial deste documento, o esboço de página reproduzido a seguir.

Suponha que a interface de ‘links cadastrados’, marcada na figura, seja um serviço de conteúdo (por exemplo, o serviço de ‘links’ do portal) e que este se repita para todos os usuários, em todas as páginas. A existência de áreas como esta é um requisito bastante comum em portais; o endereço físico e telefones de uma empresa podem aparecer em todas as páginas, por exemplo. Por ser uma informação que se mantém para todos os usuários, trata-se de uma interface que deve ser colocada em cache.

Supondo então a colocação completa desta página e de grande parte do restante do Portal em cache HTML, a alteração do conteúdo da interface marcada precisaria ser propagada em todas estas páginas. Em outras palavras, a inserção de um novo conteúdo expiraria todas as páginas do portal, e estas precisariam ser novamente geradas.

Em um portal com grande volume de conteúdos (um site de ‘notícias’, por exemplo, que pode facilmente conter centenas de milhares de páginas), é sempre indesejável a expiração de volumes tão grandes de informação de uma só vez.

Revendo a página de exemplo, é fácil perceber que outras áreas poderiam igualmente causar o mesmo problema de expiração em massa de páginas do portal. As interfaces de cabeçalho, menu lateral, menu superior, rodapé, busca e autenticação, todas potencialmente poderiam obrigar a expiração de todo o portal.

Ao ser apresentada uma estrutura de página como esta é preciso definir se este problema merece preocupação e tratamento especial. Para portais com pequeno volume de páginas ou que não tenham muitas páginas em cache HTML pode ser desnecessário atuar para minimizar o problema potencial. Outros portais podem ter séria degradação de performance se a situação não for percebida em tempo e tratada adequadamente.

Ainda nesta página, foi dito que a lista de notícias é uma lista paginada com todos os conteúdos cadastrados para uma determinada instância do serviço.

Pensando ainda em um portal com grande número de informações, este requisito pode ser um problema. A inserção de uma notícia, por exemplo, obriga a nova geração de todas as interfaces da lista paginada, pois os últimos itens de cada página passam a ser os primeiros das páginas seguintes.

Assim sendo, em um portal com cinco mil notícias paginando a cada vinte, 250 páginas de lista seriam expiradas a cada nova notícia cadastrada.

Há diversas formas de solucionar estas e outras situações que podem vir a ocorrer. Neste último exemplo, duas estratégias comuns são limitar o número de páginas geradas (apenas 10 páginas, por exemplo) ou alterar o serviço para que sejam apresentados apenas os itens com um número máximo de dias de publicação. Uma vez que estas definições alteram requisitos funcionais da solução, estas devem ser definidas em conjunto com o cliente final, em busca de um consenso. Como mencionado anteriormente, em alguns portais menores estas questões podem não ser prioritárias ou preocupantes.

De qualquer forma, é importante tentar sempre pensar em formas de aproveitar ao máximo o cache HTML, mesmo que estas não sejam implementadas no projeto. Após algum tempo esta análise fica mais imediata e automática, ajudando em projetos onde for imprescindível.

Algumas soluções comuns para problemas comuns

Interfaces que se repetem em muitas páginas podem ser inseridas como ‘server-side includes’, gerados pelo servidor web.

Com uso desta funcionalidade, o HTML da página gerada ‘inclui’ trechos HTML de outros arquivos, também gerados pelo Lumis Portal. Na figura a seguir as interfaces ‘cabeçalho’, ‘menu superior’, ‘busca’, ‘login/senha’, ‘menu lateral’, ‘rodapé’ e ‘links cadastrados’ podem ser geradas como arquivos a parte.

Na estrutura do Lumis Portal, haveria uma página para cada uma destas interfaces, estando esta página também em cache HTML. Desta forma, quando houvesse a inserção de um novo link apenas UMA página seria expirada e novamente gerada, mas o portal seria completamente alterado, uma vez que este HTML é inserido dinamicamente em cada página.

O diagrama a seguir mostra uma possível organização para estas páginas. Perceba que cada interface a ser incluída é uma página do portal, sendo esta a única efetivamente atualizada pelo Lumis Portal quando da alteração de um conteúdo.

Interfaces dinâmicas ou que possuem resultado específico para cada usuário podem ser montadas como client-side scripts.

Este tipo de ‘renderização’ é recomendada sempre que a página estiver em cache HTML, mas algumas de suas interfaces (em geral, seu ‘conteúdo’ principal) é dinâmico.

Com o uso desta funcionalidade o HTML gerado para a página carregará dinamicamente o conteúdo da interface via AJAX. Assim sendo todo o restante da página será entregue imediatamente pelo servidor web, e a área dinâmica será resolvida pelo servidor de aplicação e enviada a seguir.

A abordagem reduz o tempo de espera para carga da página e mantém o restante das interfaces em cache HTML, diminuindo com isso a carga no servidor de aplicação. No exemplo mostrado, a interface de ‘produtos em destaque’ poderia ser colocada como ‘client-side’ se os produtos listados fossem específicos para cada usuário.

Há diversas outras situações onde algum dinamismo é necessário na página, e este pode facilmente ser resolvido utilizando ‘client-side scripts’. Imagens de ‘captchas’ de formulários, por exemplo, podem ser gerados desta forma – a alternativa seria ter interface e página fora de cache, apenas por conta de um elemento.

Nem sempre uma página poderá estar completamente em cache HTML; de fato, algumas interfaces não podem ser colocadas desta forma devido a seu dinamismo. Interfaces de ‘resultados de busca’, por exemplo, são por definição dinâmicas, embora as páginas onde se encontrem instanciadas podem conter os demais elementos em cache.

Ainda assim, para portais com grande volume de acessos ou de atualizações é importante que haja uma preocupação com o uso de cache HTML. Muitos portais podem ser quase completamente colocados em cache, desde que as páginas e os serviços sejam planejados de forma a permiti-lo.

Avaliação prévia de um portal

Usualmente um projeto de portal se inicia com sua arquitetura de informação e um wireframe ou protótipo de suas páginas. Mesmo quando esses insumos ainda não existirem, geralmente será provido um mapa do site desejado, contendo alguns requisitos mínimos para uma compreensão inicial do que deve ser construído.

Antes de ser criado um layout definitivo, sabe-se o que haverá em cada página e como será a estrutura de navegação. Neste momento é comum termos também uma avaliação (mesmo que incompleta) dos perfis (grupos) que terão acesso ao portal, bem como uma visão macro dos requisitos de cada funcionalidade.

Esta é uma boa oportunidade para validar que prioridade deve ser dada à performance da solução e ao uso dos recursos. É importante, também, ter uma boa idéia do número previsto de acessos ao portal e o equipamento que se planeja utilizar.

Com o uso de cache, nem todo acesso ao portal implica em um acesso ao servidor de aplicação. Sabendo-se a configuração dos servidores e outras características da rede, é possível estimar a carga suportada e confrontá-la com o que é desejado em relação a acessos e estimativa de crescimento. A importância de agilidade do portal deve também ser levada em consideração, visto que páginas em HTML serão servidas mais rapidamente que de forma dinâmica.

Com este pré-levantamento sabe-se, então, o quanto será importante otimizar o portal em relação a cache. Embora sempre seja interessante ter a melhorperformance e o melhor uso possível de equipamentos, muitas vezes há um meio-termo aceitável que otimiza os esforços necessários para confecção do portal e mantém boa performance. Quando há necessidade de alterar requisitos para efetuar alguma melhoria, nem sempre é possível resolver da forma que seria a tecnicamente melhor.

Inicialmente devemos nos concentrar nas páginas que estimamos serem as mais acessadas, ou as que precisam de melhor resposta. A página principal de qualquer portal deve, se possível, estar integralmente em cache HTML. Sub-homes, se existirem, deveriam também estar em cache, bem como as que se considera mais ‘importantes’ no portal.

Além destas, páginas que levam muito tempo para geração dinâmica devem ser otimizadas; estão nesta lista as páginas que dependem de recursos externos ou que possuem interfaces de serviços que exigem grande processamento para sua geração.

A cada página considerada devem ser estudadas as formas de colocá-la em cache. Para cada interface, deve ser definido se o conteúdo varia a cada usuário. Em caso negativo, a interface poderia ser colocada em cache. Áreas do portal que não exigem autenticação são normalmente colocadas em cache HTML por completo.

Ainda no momento de verificação de cada interface, deve-se verificar como seu cache é expirado – no caso de haver instanciamento da mesma interface em muitas páginas, pode ser interessante considerar a possibilidade do uso de SSI. No caso da limpeza automática de cache ser ineficiente ou expirar mais interfaces que o necessário, deve-se verificar a possibilidade de dedicar algum esforço à customização de cache.

Paginação é motivo de preocupação especial pelos fatores anteriormente discutidos – vale a pena verificar a cada caso a possibilidade de limitar a paginação para o menor valor aceitável para uso do portal.

Interfaces dinâmicas devem sempre ser verificadas para eventual configuração para utilizar ‘client-side scripts’.

Algumas interfaces que parecem ser intrinsecamente dinâmicas não necessariamente precisam estar fora de cache. Mesmo um ‘banner’ que mostre uma imagem a cada vez poderia ser resolvido por HTML e JavaScript, podendo portanto ser gerada em cache.

Estes estudos alteram a forma como o portal deve ser montado e como os serviços serão construídos. Tais decisões arquiteturais, bem como seus objetivos, devem ser claramente documentadas, pois podem precisar ser revistas durante a evolução ou manutenção da solução.

Últimos ajustes

Uma vez analisada e planejada cada interface da página, e alterados os serviços ou requisitos necessários, dentro do que havia sido originalmente previsto, é possível colocar as páginas em cache HTML e testar toda a aplicação. Muitas vezes problemas não são detectados durante a homologação de um portal pelo fato dos testes terem sido feitos sem habilitação do cache. Esta atitude pode muitas vezes mascarar problemas de expiração de interfaces e páginas, que só chegam a ser percebidos em produção.

Durante a configuração de cache HTML do Portal alguns parâmetros podem ser configurados. É preciso decidir se a solução utilizará o gerador de cache ou se haverá apenas geração sob demanda. No caso da geração automática, equipamentos (servidores) específicos podem ser utilizados para este fim. Estimar o número de equipamentos necessários a esta tarefa é uma atividade importante, que deve ser revista com o monitoramento constante do ambiente.

Se for necessário, algumas páginas podem ter a geração de cache priorizada, garantindo que serão tratadas de forma diferenciada pelo gerador automático.

É importante também monitorar constantemente os servidores de aplicação e os servidores web de seus portais. Em relação a cache, este monitoramento pode apresentar a carga nos servidores, o tempo médio de geração das páginas em cache, o estado atual da fila de geração e o volume de acessos, entre diversas outras informações. Com base nestas informações decisões podem ser tomadas para otimizar ainda mais o funcionamento do portal.

Uma carga acima do esperado em servidores específicos para geração de páginas em cache pode gerar a necessidade de ampliar o número de máquinas para esta finalidade, ou investigar se mais páginas estão sendo expiradas que o necessário, e por que motivo.

Em portais com grande volume de acesso ou de informações, acompanhamento e otimizações são tarefas constantes, independendo da tecnologia utilizada.

Outra situação que deve ser acompanhada é o log de erros de geração de páginas em cache. Quando um erro acontece durante a geração de uma página, o Lumis Portal recoloca a página na fila para geração um número finito de vezes, reajustando sua prioridade adequadamente.

A ocorrência de erros de geração deve ser acompanhada constantemente; para compreender como investigar estes erros, e como proceder, consulte a documentação do Lumis Portal ou o artigo Geração de Páginas em Cache.

Perfis comuns de portais

Cada portal possui particularidades que o tornam único, mas geralmente é possível classificar portais de diversas formas. Pensar no ‘perfil’ de um portal como uma combinação destas características auxilia a tomar decisões com base no histórico de projetos anteriores.

Algumas das características que auxiliam a identificar o perfil de um portal estão listadas a seguir.

Quanto ao dinamismo de suas páginas.
Quanto ao número de acessos.
Quanto à necessidade de alta performance.
Quanto à necessidade de alta disponibilidade.
Quanto ao volume de publicação de conteúdos.
Quanto ao número de páginas do portal.
Quanto à necessidade de interação com sistemas externos.
Quanto à complexidade administrativa.
Quanto ao volume transacional.

Portais com páginas mais estáticas utilizam mais facilmente os recursos de cache providos pelo Lumis Portal. Nesta categoria podemos incluir internets corporativas e portais sem autenticação para usuários. Mesmo nestes casos algum acesso aos servidores de aplicação pode ser necessário, por exemploem serviços que submetam formulários (‘fale conosco’, ‘envie para um amigo’, ‘enquete’, etc.). Estratégias de cache para estes portais são geralmente mais simples, mas devem ser cuidadosamente trabalhadas no caso de grande volume de páginas ou de acessos.

Portais mais sistêmicos e dinâmicos têm mais dificuldade de serem colocados em cache, exigindo que interfaces dinâmicas estejam em ‘client-side’ paraagilizar o restante das páginas. Cuidado especial deve ser tomado com a sobrecarga nos servidores de aplicação no caso de ser esperado um grande volume de acessos.

Havendo necessidade de alta performance ou grande volume de acessos, mais esforço deve ser dedicado ao planejamento de cache, e na otimização de serviços. Alta disponibilidade exige também que a carga nos servidores de aplicação seja a menor possível, sendo recomendado que o portal esteja o máximo possível em cache. Ainda nestes casos é importante verificar a possibilidade de uso do gerador de cache, pré-gerando todas as páginas conforme forem expiradas. Desta forma, a indisponibilidade temporária do servidor de aplicação não impedirá a navegação dos usuários pelas páginas estáticas, que podem inclusive ser replicadas em servidores de contingência.

Alto volume de publicação de conteúdos pode exigir cuidados adicionais, uma vez que muitas páginas podem ser repetidamente expiradas. Nestes casos pode ser interessante pensar na customização dos serviços para que o cache não seja imediatamente ou automaticamente expirado.

Interação com sistemas externos usualmente faz com que a geração das páginas leve mais tempo que o esperado; neste caso pode ser interessante verificar se há alguma forma de ler previamente as informações e armazená-las em cache, sendo esta lógica de responsabilidade dos serviços a serem desenvolvidos.

Ajustes de funcionalidades que podem auxiliar a colocação de páginas em cache

A análise de cada página e do comportamento de cada serviço pode levar a formas que possam permitir ou melhorar a utilização do cache HTML para um portal. A seguir são listadas algumas das mais frequentemente vislumbradas.

Serviços que permitem publicação para usuários e grupos: neste caso, as interfaces (e, consequentemente, as páginas onde se encontram inseridas) podem apresentar informações diferentes para usuários, não sendo possível sua colocação em cache. Deve-se evitar este tipo de interface, se possível, ou tentar minimizar a situação com customização de cache, renderização via ‘client-side script’ ou outra forma aceitável para os requisitos de performance do portal.
Serviços de conteúdo com interfaces de lista contendo paginação ilimitada: potencialmente há geração de muitas páginas a cada mudança em um único conteúdo, problema que se torna maior conforme o número de acessos ao portal, taxa de atualização de informações e número de conteúdos cadastrados. Deve-se tentar limitar o número de páginas em cada interface de lista, ou que informações são paginadas (apenas as publicadas na última semana, por exemplo).
Interfaces que randomizam conteúdo: podem exigir um cuidado maior em sua colocação em cache, para que os conteúdos continuem a ser apresentados de forma aleatória. Se o requisito for indispensável, a exibição deve ser resolvida em HTML+JS, colocando desta forma as interfaces (e, se possível, as páginas onde se encontrem) em cache.
Necessidade de contabilização de acessos ou algum tipo de interação com servidor de aplicação: em alguns portais é preciso, por exemplo, saber que usuários visualizaram determinada informação ou página; ou contabilizar o número de acessos a um ‘banner’. Tal situação pode ser resolvida com requisições via JavaScript na página HTML gerada, podendo ser mantida a interface (e, potencialmente, a página) em cache.

Por mais que seja possível identificar padrões e perfis de soluções, portais são únicos por natureza, não havendo como construir um roteiro completo de verificação e análise.

O importante neste caso é conhecer o funcionamento do cache no Lumis Portal e manter uma atitude de sempre procurar utilizar ao máximo esta funcionalidade.