Configuração de JVM
Verificar se a versão do Java é da mesma arquitetura do SO (64 bits ou 32 bits)
Essa validação é importante para garantir que uma JVM de 64 bits não tente ser executada em um sistema de 32 bits (o que não é possível). Também é importante para garantir que em sistemas de 64 bits a JVM aproveite melhor os recursos do sistema de forma a aumentar o desempenho. Em geral, a arquitetura da JVM deve ser a mesma do sistema operacional.
Para maiores informações, veja essa página.
Verificar os parâmetros de memória do Java -Xmx -Xms -XX:MaxPermSize
Esses parâmetros definem os limites de memória para a JVM. São importantes para garantir que a JVM possa usar toda a memória disponível para si, mas sem tentar alocar mais memória que o disponível.
O parâmetro -Xmx define o limite máximo de memória para a JVM. O -Xms, a alocação inicial de memória. O -XX:MaxPermSize (deprecated a partir da JVM 1.8), define o tamanho máximo de alocação da área de geração permanente na JVM.
Em geral, define-se o parâmetro -Xmx igual ao -Xms, de forma que alocação de memória adicional não seja necessária.
Verificar atividade de GC
É importante verificar a atividade do Garbage Collector da JVM para investigação de uso de memória. Uma alta atividade de GC pode indicar que a memória atualmente disponibilizada para a JVM está se tornando escassa. Há diversas ferramentas para monitorar essa informação. O JDK inclui o jstat, que pode ser utilizado da seguinte forma para esse monitoramento: $ jstat -gc 30812 1s, onde: -gc indica ao jstat que queremos estatísticas de GC; 30812 é o PID da JVM; e 1s é o tempo entre coleta das estatísticas (no caso, 1 segundo). Para maiores informações sobre o jstat, veja a sua referência.
Heap dump automático ao obter um OutOfMemoryError
Ambientes de produção deveriam estar configurados para realizar um heap dump automático ao acontecer um OutOfMemoryError. Esse erro indica que a memória da JVM está esgotada. Essa situação pode acontecer pelo fato da memória disponível para a JVM não ser o suficiente para a solução ou pelo fato de existir um memory leak na solução. O heap dump pode ser utilizado para identificar quais dos dois casos está acontecendo e elencar possíveis soluções de contorno.
Normalmente, dois parâmetros da JVM são utilizados para efetuar esse dump automático:
-XX:+HeapDumpOnOutOfMemoryError: indica para a JVM que o heap dump automático deve ser realizado.
-XX:HeapDumpPath=/var/dumps/: indica para a JVM um diretório (ou arquivo) onde os dumps serão salvos.
Para maiores informações, veja essa página de referência.
Configuração de Apache
Verificar se o Virtualhost está configurado conforme documentação do Lumis Portal
É importante validar que a configuração do virtual host do Apache Httpd está de acordo com a documentação do Lumis Portal. Essa configuração serve para a correta integração entre o web server e o application server. É importante notar que essa configuração pode ser atualizada entre versões do Lumis Portal e, assim, ao atualizá-lo, essa configuração deve ser atualizada de acordo.
O DocumentRoot está configurado conforme caminho estático no gerenciador de Websites do Lumis
É importante validar que o diretório de itens estáticos que o Apache Httpd serve está corretamente configurado na configuração de Website do Lumis Portal. Caso a solução possua mais de um site, todos devem estar configurados para os diretórios de itens estáticos de acordo.
Verificar se na pasta configurada no DocumentRoot só existem arquivos estáticos, excluir todos JSP.
Por questões de segurança, é importante validar que somente itens estáticos (e de visibilidade pública) estão armazenados na pasta de itens estáticos servida pelo Apache Httpd. Dessa forma, somente itens como imagens, javascripts, CSSs, JSONs, LESSs etc (de acesso público) deveriam estar nesse diretório.
Verificar qual o nome da página inicial gerada. index.html, index.htm, pagina-inicial.htm? Colocar no DirectoryIndex do apache.
A solução pode customizar o arquivo utilizado em WebResources de canais. Esse arquivo será, por padrão e caso a solução esteja utilizando URLs amigáveis, index<extensão de arquivos HTML do portal>. Sendo que <extensão de arquivos HTML do portal> é a extensão configurada para arquivos HTML do portal. Essa extensão será, por padrão, .htm para páginas sem SSI ou .shtml para páginas com SSI (para maiores informações sobre SSI, veja essa página).
A configuração DirectoryIndex do Apache Httpd deve ser configurada para utilizar o nome desse arquivo (no padrão, index.htm).
Validar que não estão acontecendo erros 404 nas páginas (imagens, css, etc)
Recursos estáticos não encontrados no servidor web (uma imagem inexistente, por exemplo) acabam sendo redirecionados para o servidor de aplicação, o que pode causar uma degradação da performance do portal. A solução deve garantir que nenhum erro 404 de recursos estáticos está acontecendo na renderização das páginas.
Configuração de Application Server
Validar configuração
Validar que a configuração do servidor de aplicação está de acordo com as instruções do manual do Lumis Portal.
Validar número de conexões aceitas
Validar que o número de conexões aceitas no servidor de aplicação é tal que não estoure o número máximo de conexões do portal com o banco de dados.
Configurações do Lumis Portal
O cache HTML está habilitado para todo o site público?
As áreas públicas dos sites devem estar com cache HTML habilitado por questões de performance. Dessa forma, todas as páginas públicas seriam servidas pelo web server de forma otimizada aos usuários.
Verificar se as instâncias do serviço de mídias, documentos ou imagens estão ou podem estar com o parâmetro arquivos públicos habilitados.
Instâncias dos serviços de repositório de mídias, documentos, álbum de fotos e álbum de mídias podem ser configuradas para seus arquivos serem públicos (assim como quaisquer outros serviços que possuam arquivos em seus dados). Aquelas instâncias que possuem dados públicos (ou seja, arquivos acessíveis por quaisquer usuários, logados ou não) devem estar configuradas para utilizar arquivos públicos por questões de performance.
Monitor está ligado? Realmente existe a necessidade?
O Lumis Portal possui um framework de monitoramento, que permite que estatísticas de determinados eventos (como visualização de páginas, por exemplo) sejam armazenadas e consultadas. Caso essas estatísticas não sejam desejadas pela solução, esse framework pode ser desligado. Para maiores informações, veja essa página.
E a configuração dos threads para geração de cache?
A configuração de geração de cache deve ser adaptada de acordo com a solução e ambiente adotados. Essa configuração, em especial o número de threads dos geradores, pode influenciar na performance de geração de cache HTML.
Como está a configuração de pool de banco de dados, qual o limite de conexão?
O número de conexões simultâneas do Lumis Portal com o banco de dados relacional deve estar de acordo com a solução. Em geral, esse número deve comportar os processos em segundo plano executados (geradores de cache, tarefas agendadas etc) e as requisições dos usuários. Essa configuração é totalmente dependente da solução adotada e deve ser definido em tempo de projeto.
Propriedades a serem configuradas (no arquivo lumishibernate.cfg.xml):
maxActive: Indica o número máximo de conexões ativas com o banco de dados relacional. Ao ser atingido esse número, erros no portal podem acontecer. É importante que esse número nunca seja ultrapassado.
maxIdle: Máximo de conexões inativas. O pool de conexões irá terminar as conexões inativas ao ser ultrapassado esse limite.
minIdle: Mínimo de conexões inativas a serem mantidas, de forma que uma requisição de conexão seja rápida.
Para maiores informações, veja essa página.
Verificar nível de log no arquivo lumislogconfig.xml. Em ambiente de produção o nível debug não deveria estar ativado.
É altamente recomendável que em produção o nível de log esteja em um nível acima de DEBUG (idealmente WARN). O log de DEBUG escreve muitas mensagens, o que pode degradar a performance do portal como um todo. Maiores informações aqui.
Verificar no logfull os erros ocorrendo.
Constantemente, administradores de sistema devem acompanhar os logs (do application server, do web server, do repositório de big data, do banco de dados etc) para verificar existência de falhas para que possam ser adotadas medidas corretivas. Utilizando a configuração padrão de logs do Lumis Portal, a melhor fonte de dados de erros no Lumis Portal é o arquivo <local da instalação do Lumis Portal>/lumisdata/log/full/ logfull.log. Deve ser acompanhado nesse arquivo (ou no arquivo adequado à configuração utilizada no ambiente) erros que estejam ocorrendo.
Verificar configuração do tempo de persistência das mensagens duráveis.
O Lumis Portal ao ser utilizado em cluster, por padrão, armazena as mensagens duráveis trocadas entre os servidores. Isso serve para que um servidor possa, após ficar um tempo fora do ar, alcançar o estado dos servidores mais atualizados. Existe uma configuração no portal que indica o tempo que essas mensagens devem ser mantidas armazenadas. Como essas mensagens são persistidas em banco de dados relacional e podem ser relativamente grandes (elas armazenam, por exemplo, os arquivos trocados entre os servidores), é recomendado que esse tempo de vida das mensagens duráveis seja configurado de acordo com a realidade da solução e do ambiente adotado.
As instâncias de interfaces estão com cache habilitado?
O Lumis Portal possui um mecanismo de cache que pode ser aplicado nas instâncias de interface. As instâncias de interface que podem ter cache habilitado devem estar configuradas para tal. É importante notar que o cache da instância de interface pode ter níveis diferentes. Ele pode ser em nível de página ou de template. Caso possa, ela deve ser cacheada em nível de template para uma melhor performance. Para maiores informações, veja essa página.
Existem bibliotecas antigas em WEB-INF/lib?
É de suma importância que ao atualizar o Lumis Portal seja validado que bibliotecas antigas do portal sejam removidas, de forma a evitar conflitos e comportamentos não esperados.
O tipo de ambiente está corretamente configurado?
É de suma importância que o tipo de ambiente esteja configurado de acordo. Essa configuração pode ser encontrada nessa página.
O tipo de repositório de Big Data utilizado é Elasticsearch embutido?
Em ambientes de produção ou ambientes que possuam cluster ativado, essa configuração não deve ser feita. Essa configuração pode ser encontrada nessa página.
Como extrair dados de tempo de execução de interfaces dos dados de monitoramento?
Para extrair informações sobre as interfaces que mais estão demorando para serem renderizadas, basta executar a seguinte query (lembrando que, para que esses dados existam, o monitoramento de renderização deve estar ativado):
SELECT eda.value, MAX(edm.maximumValue) FROM lum_MonEventData ed INNER JOIN lum_MonEventDataAggregation eda on ed.id = eda.eventDataId INNER JOIN lum_MonEventDataMeasure edm on edm.eventDataId = ed.id WHERE ed.eventId in (SELECT id FROM lum_MonEvent WHERE eventKey = 'lumis.portal.servicecontainer.ev.serviceinterfaceinstance.renderization') AND eda.aggregationTypeId in (SELECT id FROM lum_MonAggregationType WHERE aggregationTypeKey = 'lumis.portal.monitor.at.serviceinterface.id') AND edm.measureTypeId in (SELECT id FROM lum_MonMeasureType WHERE measureTypeKey = 'lumis.portal.monitor.mt.duration.ms') GROUP BY eda.value ORDER BY 2 DESC
Maiores informações sobre extração de dados de monitoramento, veja nessa página.
Possíveis causas e soluções para problemas de performance na auto administração
Caso o portal esteja enfrentando uma lentidão na área de auto administração, pode-se tentar criar outra instância do serviço de auto administração, de forma que a árvore gerenciada pela instância de serviço seja menor. Caso o problema de lentidão seja sanado com essa medida, é sugerido que uma alteração dessa seja feita, de forma a melhorar a performance da auto administração.
Lentidão no gerador de cache
Muitas vezes a solução não adota cache de interface, já que ela utilizará cache HTML. Porém, caso as interfaces não estejam em cache, os geradores de cache podem acabar sofrendo uma lentidão desnecessária. É sugerido que as interfaces que possam ficar em cache o façam, mesmo que a solução esteja utilizando cache HTML.
Outra possível causa da lentidão é a falta de configuração do elemento htmlGeneration/frameworkUrl. Caso essa configuração não esteja presente, o portal utilizará a URL principal não segura do Website padrão do portal. Isso pode fazer, dependendo da solução, que a requisição para gerar as páginas em cache tenham que realizar DNS lookup, passar por roteadores, load balancers, web servers etc até que chegue, então, ao portal. Dependendo da arquitetura de solução adotada, pode ser possível configurar esse elemento como localhost, para que a requisição do portal não passe por todas essas camadas desnecessárias.
Servidor
Consumo de memória
Os administradores do sistema devem acompanhar o consumo de memória, de todos os servidores do sistema (servidores web, servidores de aplicação, servidores de banco, servidores de big data etc), para poder tomar medidas corretivas. No Lumis Portal, os administradores podem usar a interface do JavaMelody para acompanhar o consumo de memória, além dos logs, em busca de OutOfMemoryErrors.
O Lumis Portal tem característica de tentar utilizar o máximo de memória o possível para cachear objetos. Para se medir o real consumo de memória do mesmo, é possível que seja necessário forçar algumas limpezas de GC.
Consumo de CPU
No Lumis Portal os administradores devem acompanhar o uso de CPU para identificar possíveis problemas e limitações do sistema. Novamente, a interface do JavaMelody dá um resumo de uso de CPU.
No banco de dados, os administradores devem acompanhar o consumo de CPU, inclusive analisando queries pesadas e demoradas para poder adotar medidas corretivas. Caso o banco de dados esteja com performance degradada, deverá ser investigado se existe alguma outra aplicação sendo executada no mesmo banco de dados que possa estar influenciando negativamente a performance do portal.
Utilização de disco
A utilização de disco deve ser monitorada para identificar possíveis gargalos de IO. Uma alta utilização de disco pode indicar, também, uma escassez de memória (o que acarretaria em muito acesso à área de swap do sistema).
Esse monitoramento deve ser realizado em todos os servidores (web, de aplicação, de banco de dados, de big data) do ambiente, para elencar possíveis medidas corretivas.
Além da atividade do disco, deve-se monitorar o espaço em disco para evitar problemas de escrita por parte do portal.