15 melhores dicas de ajuste de desempenho do Oracle APEX para desenvolvedores

Olá Habra!

Hoje nossa empresa tem 28 anos e, em homenagem a este evento agradável, decidimos compartilhar um novo material com você.

Obrigado por sua ajuda na tradução de nosso autor regular Yuri PonomarevOBIEESuporte.

A autora do artigo é Michelle Scamin, fundadora e parceira administrativa da empresa que fornece o serviço Reading Rewards. Em 2009, Michelle sofria com o fato de seus filhos, de 8 e 9 anos, lerem muito pouco. Os livros simplesmente não podiam competir com computadores e videogames, então Michelle e seu marido decidiram desenvolver um sistema no qual as crianças ganhavam tempo em jogos de computador lendo livros.

Como consultora de TI e desenvolvedora de aplicativos da web, Michelle desenvolveu um software que permite que as crianças gravem o tempo que lêem e assistem à TV, e os pais acompanhem esse tempo. Este foi o início do serviço Reading Rewards.

E agora, de fato, um artigo.



Então, você escolheu um incrível aplicativo Oracle APEX para velocidade recorde - não precisará escrever muito. E, como diz o velho ditado, o que ser - isso não pode ser evitado!

Em 2010, criei um aplicativo para tentar fazer meus dois filhos pequenos lerem. Eu admito que, naquela época, eu não pensava em desempenho, e havia algumas suculentas "contagens de seleção (*) de uma mesa enorme" espalhadas estrategicamente por todo o código.

Ei, meus meninos não leram muito, então essas tabelas eram bem pequenas na época ...

Digamos que eu era muito ingênuo quando liberei o aplicativo ao público e não esperava que a carga nele fosse milhares de usuários diariamente, gerando 150.000 visualizações de página por dia.


Estatísticas do Google Analytics

Além do fato de todo esse interesse ter sido muito empolgante para mim, eu não estava preparado para tantos cliques. Eu tive problemas de desempenho. Você apenas precisa admitir que me tornei um aluno ávido do ajuste de desempenho do Oracle APEX e pensei em compartilhar algumas das coisas que aprendi ao longo dos anos.

Como identificar um gargalo?


Você deve prestar atenção em muitas coisas ao avaliar o desempenho do seu aplicativo. Você vai querer considerar os problemas associados a ele, o navegador. Problemas de rede. Configuração ORDS. Configuração do banco de dados, incluindo possíveis índices ausentes. Existem bloqueios de banco de dados no jogo? Expectativas?

Assim que você sentir que sua infraestrutura subjacente está em boas condições e sem falhas, talvez seja hora de voltar sua atenção para o próprio aplicativo, tendo em mente seu front-end (Javascript e CSS) e back-end (SQL e PL / SQL).

1. Front-end: a ordem dos arquivos é importante


Antes de tudo, se você incluir componentes CSS e JS personalizados, verifique se o CSS está na parte superior da página e o JavaScript na parte inferior .

Isso garante que seus usuários obtenham pelo menos os componentes da interface do usuário, mesmo que alguns arquivos de lógica de negócios ainda não estejam carregados.

2. Exibir monitor de atividades


Este é sempre um ótimo lugar para começar. Se tudo parecer lento e você não souber onde procurar, o monitor de atividades no ambiente de desenvolvimento APEX poderá fornecer informações valiosas.


Link para o monitor de atividades no console de desenvolvimento APEX

Todas as visualizações de página em seu espaço de trabalho e aplicativos são registradas, incluindo informações sobre o usuário, carimbo de data / hora, aplicativo, page_id e, o mais importante, a hora em que o aplicativo estava em execução.

Meu relatório de exibição de página favorito é "Por desempenho ponderado da página".




Veja o exemplo do monitor de atividades APEX

Preste muita atenção a qualquer página que tenha um grande número de eventos da página (o que é visitado com frequência) e o alto valor do tempo de execução médio do aplicativo. Lembro-me de como Joel Kalman disse uma vez que tudo acima de 0,5 segundos deveria ser revisto. Obviamente, essa é uma generalização bastante grosseira e pode (não) se relacionar ao seu caso específico de uso do APEX.

O monitor de atividades facilita o trabalho com o IR, mas se você precisar de um pouco mais de detalhes e desejar executar relatórios em diferentes áreas de trabalho, poderá usar a seguinte consulta no SQL Developer para torná-lo o mais detalhado possível:

select workspace
      , application_name 
      , application_id, page_id
      , count(*) total_page_events
      , avg(elapsed_time) avg_elapsed_time
      , sum(elapsed_time) elapsed_time
from apex_workspace_activity_log
where view_date between to_date('201911190900','RRRRMMDDHH24MISS') and to_date('201911191200','RRRRMMDDHH24MISS')
group by workspace, application_name, application_id, page_id
order by 6, 7 asc 

3. # TIMING # variável de pesquisa


Então você pode ter encontrado uma página lenta. E agora?

Bem, você pode usar a variável de pesquisa # TIMING # no rodapé das regiões do seu relatório se desejar recuperar e exibir o tempo decorrido. Isso pode ajudar a identificar as áreas mais lentas do relatório na página para as quais você pode voltar sua atenção. Isso é especialmente útil nas páginas do painel em que você pode ter muito trabalho.


Usando a linha de substituição # TIMING # no rodapé do relatório A

execução do relatório fornecerá o resultado:



Uma coisa que eu gosto nessa função não é necessariamente que ela determina quais regiões demoram muito tempo para serem executadas (eu poderia obter isso do meu janelas de depuração, veja abaixo), mas oferece informações aos usuários finais.

Muitas vezes, acho que eles solicitarão dados que eu sei que serão visualizados por idades. No mínimo, isso lhes dá uma idéia do que pode acontecer e por que eles tiveram que esperar um pouco mais por sua página do que o esperado.

4. Execute a página no modo de depuração


Melhor ainda, execute-o no Debug LEVEL9 para acessar o plano de execução do seu relatório.


A janela de depuração mostrará tudo o que acontece na sua página e mostrará o tempo de execução de cada componente. LEVEL9 irá gerar toneladas de linhas, mas você pode classificá-las em ordem decrescente de tempo para mostrar que sua página leva mais tempo para renderizar.

5. Cuidado ao chamar v (”)


Se você encontrar um relatório com desempenho insatisfatório, poderá verificar se utilizou a notação v (”) quando poderia usar a variável de ligação.

select task_name
from tasks
where assigned_to=:APP_USER

ou

select task_name
from tasks
where assigned_to=v('APP_USER')

Em uma tabela grande, a diferença entre as duas instruções pode ser enorme, porque v (”) é realmente uma chamada de função. Isso significa que você não aproveitará nenhum índice e a consulta resultará em uma verificação completa da tabela.

Dica: se você precisar fazer referência ao estado de uma sessão APEX em uma exibição (onde não é possível usar variáveis ​​de ligação), considere usar uma subconsulta escalar que possa funcionar quase tão bem quanto sua variável de ligação. Vejo:

select task_name
from tasks
where assigned_to = (select v('APP_USER') from dual)

Agradeço a John Scott por oferecer isso em um dos eventos que participei.

6. Evite a substituição de strings nas consultas, se possível


Cuidado com as seqüências de pesquisa nas consultas.

Considere, por exemplo, uma situação em que você pode precisar de uma decodificação ou instrução de caso em uma consulta para determinar para qual página você deseja ramificar:

select case when dept_no=20 then
          'f?p=&APP_ID.:3:&SESSION.::::P3_DEPTNO:'||deptno
       else
          'f?p=&APP_ID.:2:&SESSION.::::P2_DEPTNO:'||deptno
       end as link
       , deptno
       , dname
from dept

Usando a variável de ligação: SESSION, não a cadeia de pesquisa & SESSION. pode fazer uma enorme diferença e economizar muito tempo para analisar o Oracle. A versão da variável de ligação permite que o Oracle reutilize a consulta.

select case when dept_no=20 then
          'f?p=&APP_ID.:3:'|| :SESSION ||'::::P3_DEPTNO:'||deptno
       else
          'f?p=&APP_ID.:2:'|| :SESSION ||'::::P2_DEPTNO:'||deptno
       end as link
       , deptno
       , dname
from dept

Se você estiver interessado em aprender mais sobre isso, confira o maravilhoso vídeo de Jorge Rimblas sobre seqüências de caracteres curinga, variáveis ​​de ligação e links APEX.

7. Use parâmetros declarativos em suas condições quando possível


Ao usar condições nos componentes da página, sempre use parâmetros declarativos sempre que possível. Eles serão muito mais eficazes.


8. Use as configurações de paginação racionalmente


Em relatórios grandes, as opções de paginação selecionadas podem ter um efeito significativo. Apesar do fato de que desde a versão 18.1 APEX melhorou significativamente o processamento de paginação (leia esta maravilhosa postagem de Karsten Charsky), você pode desativar o parâmetro "intervalo de linhas de X a Y de Z" em uma delas, se tiver problemas de desempenho em um relatório muito grande.


9. Evite HTML nas consultas e use uma expressão HTML


Sempre que possível, use o atributo de expressão HTML para as colunas do relatório para incluir quaisquer atributos HTML / CSS necessários.

10.


Assim, você identificou uma área de relatório muito lenta que configurou da melhor maneira possível.

Preciso atualizar os dados sempre que visualizo a página? Pense nos relatórios do painel, em particular nos dados de vendas, etc. Até os dados da transação recebidos 1 minuto atrás podem ser bastante completos em muitos casos.

Nesse caso, você pode usar a opção de cache da região.



Configurações de cache do servidor nas regiões APEX.

Por padrão, o armazenamento em cache está desativado, mas se você o habilitar, poderá selecionar a opção de tempo limite do cache, iniciando em apenas 10 segundos. Até 10 segundos ajudarão o desempenho do painel, usado por um grande número de usuários! E é óbvio que aumentar esse parâmetro ajudará ainda mais.

Cuidado, se você tiver dados confidenciais que dependem do usuário, poderá selecionar as opções "cache por usuário" ou mesmo "cache por sessão".


Configurações disponíveis ao ativar o armazenamento em cache regional

Se você decidir ativar o armazenamento em cache, poderá informar seus usuários sobre a atualização de dados mais recente. Nesse caso, você pode usar a função APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE .

11. Mova PL / SQL para pacotes


Certifique-se de mover o código para pacotes. Eles já estão compilados no banco de dados, o que significa que haverá menos sobrecarga para a análise dinâmica.

Os processos da sua página devem ser apenas chamadas de pacotes sempre que possível.

Stephen Feuerstein escreveu um artigo muito detalhado sobre como escrever o PL / SQL para Oracle Application Express , que você pode ler. Ela já tem vários anos, mas ainda é relevante!

12. Inicie o Supervisor!


Raramente vejo pessoas usando esse ótimo recurso, mas isso é algo que todos devemos fazer regularmente. Toda vez que me pergunto o que mais ele encontra.


13. Use as opções de construção para desativar e ativar componentes


Bem, você tentou TODAS ESTAS COISAS, mas ainda está preso, não está claro o que. Se você deseja “redesenhar sua página novamente”, considere o uso de opções de compilação para os vários componentes da sua página.

Não coloque condições indefinidas nos componentes, caso contrário você perderá todas as suas preciosas condições! Além disso, os componentes perpétuos têm o recurso desagradável de viver em seus aplicativos para sempre ...

Crie um novo parâmetro de construção usando Status: Excluir.

Aplique-o alternadamente aos vários componentes da sua página. Inicie sua página com cada alteração e veja se funciona melhor. Se sua página repentinamente correr mais rápido, você pode ter encontrado os culpados.

14. Entenda como várias configurações de IR podem afetar o desempenho do APEX.


Com um relatório interativo mal executado, várias configurações, parâmetros ou filtros aplicados pelos usuários podem exacerbar um trabalho ruim (sim, é mesmo).

Como mencionado anteriormente, é melhor começar usando o modo de depuração LEVEL9 e configurar uma consulta real separada. Examine o plano de execução, examine os índices, ajuste sempre que possível. Lembre-se de que cada visualização (tabela, agrupamento, gráfico, resumo) é uma consulta separada que pode exigir personalização. Em seguida, ele muda novamente ao usar o filtro de pesquisa ou o filtro de cabeçalho da coluna!

Sua configuração MaxRowCount também entra em jogo, e você deve tentar torná-la a menor possível. Não existe uma resposta certa para isso, e talvez você precise jogar com números diferentes antes de conseguir algo que funcione para seus usuários.

Basicamente, considere excluir ou alterar alguns cenários de comportamento padrão. Os desenvolvedores têm muitos controles quando se trata de quais recursos estão habilitados para os usuários. Vale a pena tentar várias configurações e não se esqueça de consultar seus usuários para garantir que você entenda completamente os requisitos deles.

Por fim, se você achar que seu IR ainda está muito lento, considere duas alternativas:

  1. Funções de tabela de pipeline (selecione * da tabela (my_rpt_pipelined)) -> elas podem funcionar muito melhor em consultas complexas.
  2. Gerar relatório de cobrança (APEX_COLLECTION)

Agradecemos a Karen Cannell por essas dicas de IR super úteis.

15. Rastreio


Quando tudo mais falhar, você poderá adicionar "& p_trace = YES" ao final do seu URL para criar um arquivo de rastreamento que você possa analisar usando o utilitário TKPROF.

Mais informações sobre rastreamento de SQL podem ser encontradas aqui .

Ainda preso? Sempre fico impressionado com a capacidade de resposta da comunidade Oracle APEX . Dê uma mãozinha, peça ajuda em vários fóruns ou no Twitter, alguém definitivamente o indicará na direção certa. Recebi inúmeras respostas a pedidos de ajuda. Você encontrará a resposta! Lembre-se: este não é o APEX, é o mais frequente você, você mesmo :-)

All Articles