15 mejores consejos de ajuste de rendimiento de Oracle APEX para desarrolladores

Hot Habra Hola a todos!

Hoy nuestra empresa tiene 28 años y, en honor a este agradable evento, decidimos compartir nuevo material con usted.

Gracias por su ayuda con la traducción de nuestro autor habitual, Yuri Ponomarev.OBIEES apoyo.

La autora del artículo es Michelle Scamin, fundadora y socia administradora de la compañía que brinda el servicio Reading Rewards. En 2009, Michelle sufría por el hecho de que sus hijos, de 8 y 9 años, leían muy poco. Los libros simplemente no podían competir con las computadoras y los videojuegos, por lo que Michelle y su esposo decidieron desarrollar un sistema en el que los niños ganaran tiempo en juegos de computadora leyendo libros.

Como consultora de TI y desarrolladora de aplicaciones web, Michelle ha desarrollado un software que permite a los niños registrar el tiempo que leen y ven la televisión, y a los padres a seguir este momento. Este fue el comienzo del servicio Reading Rewards.

Y ahora, de hecho, un artículo.



Por lo tanto, ha elegido una sorprendente aplicación Oracle APEX para una velocidad récord: no tendrá que escribir mucho. Y, como dice el viejo dicho, qué ser, ¡eso no se puede evitar!

En 2010, creé una aplicación para intentar que mis dos hijos pequeños leyeran. Admito que en ese momento no pensaba en el rendimiento, y tenía algunos jugosos "recuento selectivo (*) de una gran mesa" estratégicamente dispersos por todo el código.

Hola, mis muchachos realmente no leían mucho, así que estas tablas eran bastante pequeñas en ese momento ...

Digamos que era bastante ingenuo cuando lancé la aplicación al público, y no esperaba que la carga fuera miles de usuarios diariamente, generando 150,000 páginas vistas por día.


Estadísticas de Google Analytics

Además del hecho de que todo este interés fue muy emocionante para mí, no estaba preparado para tantos clics. Tuve problemas de rendimiento. Solo tiene que admitir que me convertí en un ávido estudiante de ajuste de rendimiento de Oracle APEX y pensé que compartiría algunas de las cosas que aprendí a lo largo de los años.

¿Cómo identificar un cuello de botella?


Hay muchas cosas a las que debe prestar atención al evaluar el rendimiento de su aplicación. Deberá considerar los problemas asociados con él, el navegador. Problemas de red Configuración de ORDS. Configuración de la base de datos, incluidos los posibles índices faltantes. ¿Hay bloqueos de bases de datos en el juego? ¿Expectativas?

Tan pronto como sienta que su infraestructura subyacente está en buenas condiciones y no tiene la culpa, puede ser el momento de centrar su atención en la aplicación en sí, teniendo en cuenta su interfaz (Javascript y CSS) y el back-end (SQL y PL / SQL).

1. Frontend: el orden de los archivos es importante


En primer lugar, si incluye componentes CSS y JS personalizados, asegúrese de que su CSS esté en la parte superior de la página y que JavaScript esté en la parte inferior .

Esto garantiza que sus usuarios al menos obtengan los componentes de la interfaz de usuario, incluso si algunos archivos de lógica de negocios aún no están cargados.

2. Ver monitor de actividad


Este es siempre un gran lugar para comenzar. Si todo parece lento y no sabe dónde buscar, el monitoreo de actividad en el entorno de desarrollo APEX puede proporcionar información valiosa.


Enlace al monitor de actividad desde la consola de desarrollo APEX

Se registran todas las páginas vistas en su área de trabajo y aplicaciones, incluida la información sobre el usuario, la marca de fecha / hora, la aplicación, page_id y, lo más importante, la hora en que se ejecutó la aplicación.

Mi informe de visitas de página favorito es "Por rendimiento de página ponderado".




Ver ejemplo del monitor de actividad APEX

Preste mucha atención a las páginas que tienen una gran cantidad de Eventos de página (es decir, visitas frecuentes) y el alto valor del tiempo de ejecución promedio de la aplicación. Me parece recordar cómo Joel Kalman dijo una vez que todo lo que está por encima de 0,5 segundos debería revisarse. Por supuesto, esta es una generalización bastante cruda y puede (no) relacionarse con su caso específico de usar APEX.

El monitor de actividad facilita el trabajo con IR, pero si necesita un poco más de detalle y desea ejecutar informes en diferentes espacios de trabajo, puede usar la siguiente consulta en SQL Developer para que sea lo más detallado posible:

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 # variable de búsqueda


Entonces puede que hayas encontrado una página lenta. ¿Y ahora qué?

Bueno, puede usar la variable de búsqueda # TIMING # en el pie de página de sus regiones de informe si desea recuperar y mostrar el tiempo transcurrido. Esto puede ayudarlo a identificar las áreas más lentas del informe en la página a las que puede dirigir su atención. Esto es especialmente útil en las páginas del tablero donde puede tener mucho trabajo.


Usando la línea de sustitución # TIMING # en el pie de página del informe.

Ejecutar el informe dará el resultado:



Una cosa que me gusta de esta función no es necesariamente que determine qué regiones tardan mucho tiempo en ejecutarse (podría obtener esto de mi depurar ventanas, ver más abajo), pero ofrece información a los usuarios finales.

A menudo encuentro que solicitarán datos que sé que se visualizarán por años. Por lo menos, les da una idea de lo que podría suceder y por qué tuvieron que esperar un poco más de lo esperado.

4. Ejecute la página en modo de depuración


Mejor aún, ejecútelo en Debug LEVEL9 para acceder al plan de ejecución de su informe.


La ventana de depuración le mostrará todo lo que sucede en su página, y le mostrará el tiempo de ejecución de cada componente. LEVEL9 generará toneladas de líneas, pero puede ordenarlas en orden descendente de tiempo para mostrar que su página tarda más en renderizarse.

5. Cuidado con llamar a v (”)


Si encuentra un informe de bajo rendimiento, puede verificar si usó la notación v (”) cuando pudo usar la variable de vinculación.

select task_name
from tasks
where assigned_to=:APP_USER

o

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

En una tabla grande, la diferencia entre las dos declaraciones puede ser enorme, porque v (”) es en realidad una llamada a la función. Esto significa que no aprovechará ningún índice y la consulta dará como resultado un escaneo completo de la tabla.

Consejo: si necesita hacer referencia al estado de una sesión APEX en una vista (donde no puede usar variables de enlace), considere usar una subconsulta escalar que pueda funcionar casi tan bien como su variable de enlace. Ver:

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

Gracias a John Scott por ofrecer esto en uno de los eventos a los que asistí.

6. Evite la sustitución de cadenas en consultas, si es posible


Tenga cuidado con las cadenas de búsqueda en las consultas.

Considere, por ejemplo, una situación en la que podría necesitar una decodificación o una declaración de caso en una consulta para determinar a qué página desea bifurcar:

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 la variable de enlace: SESSION, no la cadena de búsqueda & SESSION. puede marcar una gran diferencia y ahorrarle a Oracle mucho tiempo de análisis. La versión variable de enlace permite a Oracle reutilizar la 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

Si está interesado en aprender más sobre esto, vea el maravilloso video de Jorge Rimblas sobre cadenas comodín, variables de enlace y enlaces APEX.

7. Use parámetros declarativos en sus condiciones cuando sea posible


Cuando use condiciones en los componentes de la página, use siempre parámetros declarativos siempre que sea posible. Serán mucho más efectivos.


8. Use la configuración de paginación racionalmente


En informes grandes, las opciones de paginación seleccionadas pueden tener un efecto significativo. A pesar de que desde la versión 18.1 APEX ha mejorado significativamente el procesamiento de paginación (lea esta maravillosa publicación de Karsten Charsky), puede deshabilitar el parámetro "rango de líneas de X a Y de Z" en uno de ellos si tiene problemas de rendimiento en un informe muy extenso


9. Evite HTML en consultas y use una expresión HTML


Cuando sea posible, use el atributo de expresión HTML para las columnas del informe para incluir cualquier atributo HTML / CSS que pueda necesitar.

10.


Por lo tanto, ha identificado un área de informe realmente lenta que ha configurado lo mejor posible.

¿Necesito actualizar los datos cada vez que veo la página? Piense en los informes del tablero, en particular los datos de ventas, etc. Incluso los datos de transacciones recibidos hace 1 minuto pueden ser bastante completos en muchos casos.

Si es así, puede usar la opción de almacenamiento en caché de la región.



Configuración de caché del servidor en regiones APEX.

De forma predeterminada, el almacenamiento en caché está desactivado, pero si lo habilita, puede seleccionar la opción de tiempo de espera de caché, comenzando con solo 10 segundos. ¡Incluso 10 segundos ayudarán al rendimiento del tablero, que es utilizado por una gran cantidad de usuarios! Y es obvio que aumentar este parámetro ayudará aún más.

Precaución, si tiene datos confidenciales que dependen del usuario, puede seleccionar las opciones "caché por usuario" o incluso "caché por sesión".


Configuraciones disponibles al habilitar el almacenamiento en caché regional

Si decide habilitar el almacenamiento en caché, puede informar a sus usuarios sobre la última actualización de datos. Si es así, puede usar la función APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE .

11. Mueva PL / SQL a paquetes


Asegúrese de mover el código a los paquetes. Ya están compilados en la base de datos, lo que significa que habrá menos gastos generales para el análisis dinámico.

Los procesos de su página deben ser solo llamadas de paquete siempre que sea posible.

Stephen Feuerstein ha escrito un artículo muy detallado sobre cómo escribir PL / SQL para Oracle Application Express , que es posible que desee leer. ¡Ya tiene varios años, pero sigue siendo relevante!

12. ¡Asesor de lanzamiento!


Raramente veo personas usando esta gran característica, pero esto es algo que todos deberíamos hacer regularmente. Cada vez que me pregunto qué más encuentra.


13. Use las opciones de compilación para deshabilitar y habilitar componentes


Bueno, probaste TODAS ESTAS COSAS, pero aún así no está claro qué. Si va a "volver a dibujar su página nuevamente", debería considerar usar las opciones de compilación para los diversos componentes de su página.

¡No coloque condiciones indefinidas en los componentes, de lo contrario perderá todas sus preciosas condiciones! Además, los componentes perpetuos tienen la característica desagradable de vivir en sus aplicaciones para siempre ...

Cree un nuevo parámetro de compilación utilizando Estado: Excluir.

Aplíquelo alternativamente a los diversos componentes de su página. Comience su página con cada cambio y vea si funciona mejor. Si su página de repente se ejecuta más rápido, es posible que haya encontrado a los culpables.

14. Comprenda cómo varias configuraciones de IR pueden afectar el rendimiento de APEX.


Con un informe interactivo mal ejecutado, varias configuraciones, parámetros o filtros aplicados por sus usuarios pueden exacerbar el mal trabajo (sí, realmente lo es).

Como se mencionó anteriormente, es mejor comenzar usando el modo de depuración LEVEL9 y configurar una consulta real separada. Examine el plan de ejecución, examine los índices, sintonice donde sea posible. Recuerde que cada vista (tabla, agrupación, gráfico, resumen) es una consulta separada que puede requerir personalización. ¡Luego cambia nuevamente cuando se usa el filtro de búsqueda o el filtro de encabezado de columna!

Su configuración MaxRowCount también entra en juego, y debe intentar que sea lo más pequeña posible. No hay una respuesta correcta a esto, y es posible que tenga que jugar con diferentes números antes de obtener algo que funcione para sus usuarios.

Básicamente, considere eliminar o cambiar algunos escenarios de comportamiento predeterminados. Los desarrolladores tienen muchos controles cuando se trata de qué características están habilitadas para los usuarios. Vale la pena probar varias configuraciones, y no olvide consultar con sus usuarios para asegurarse de que comprende completamente sus requisitos.

Finalmente, si encuentra que su IR aún es demasiado lenta, puede considerar 2 alternativas:

  1. Funciones de la tabla del transportador (seleccione * de la tabla (my_rpt_pipelined)) -> pueden funcionar mucho mejor en consultas complejas.
  2. Generar informe de recopilación (APEX_COLLECTION)

Gracias a Karen Cannell por estos consejos IR muy útiles.

15. Traza


Cuando todo lo demás falla, puede agregar "& p_trace = YES" al final de su URL para crear un archivo de rastreo que puede analizar utilizando la utilidad TKPROF.

Puede encontrar más información sobre el rastreo de SQL aquí .

¿Todavía atascado? Siempre me sorprende la capacidad de respuesta de la comunidad Oracle APEX . Dé una mano, pida ayuda en varios foros o en Twitter, alguien definitivamente lo guiará en la dirección correcta. He recibido innumerables respuestas a las llamadas de ayuda. ¡Encontrarás la respuesta! Solo recuerde: esto no es APEX, con frecuencia es usted, usted mismo :-)

All Articles