Hot Habra Bonjour à tous!Aujourd'hui, notre entreprise a 28 ans, et en l'honneur de cet événement agréable, nous avons décidé de partager du nouveau matériel avec vous.Merci de votre aide pour la traduction de notre auteur régulier Yuri PonomarevOBIEESupport.L'auteur de l' article est Michelle Scamin, fondatrice et associée directrice de l'entreprise qui fournit le service Reading Rewards. En 2009, Michelle souffrait du fait que ses fils, âgés de 8 et 9 ans, lisaient trop peu. Les livres ne pouvaient tout simplement pas rivaliser avec les ordinateurs et les jeux vidéo, alors Michelle et son mari ont décidé de développer un système dans lequel les enfants gagnaient du temps sur les jeux informatiques en lisant des livres.En tant que consultante en informatique et développeur d'applications Web, Michelle a développé un logiciel qui permet aux enfants d'enregistrer le temps qu'ils lisent et regardent la télévision, et aux parents de suivre ce temps. Ce fut le début du service Reading Rewards.Et maintenant, en fait, un article.
Vous avez donc choisi une incroyable application Oracle APEX pour la vitesse d'enregistrement - vous n'aurez pas à écrire beaucoup. Et, comme le dit le vieil adage, que faire - cela ne peut être évité!En 2010, j'ai créé une application pour essayer de faire lire mes deux petits fils. J'avoue qu'à ce moment-là je ne pensais pas aux performances, et il y avait quelques "jauges sélectives (*) à partir d'une immense table" juteusement dispersées stratégiquement dans le code.Hé, mes garçons ne lisaient pas vraiment beaucoup, donc ces tableaux étaient assez petits à l'époque ...Disons simplement que j'étais assez naïf quand j'ai publié l'application au public, et je ne m'attendais pas à ce qu'elle se charge des milliers d'utilisateurs par jour, générant 150 000 pages vues par jour.
Statistiques de Google AnalyticsOutre le fait que tout cet intérêt était très excitant pour moi, je n'étais pas du tout prêt pour autant de clics. J'ai eu des problèmes de performances. Vous devez juste admettre que je suis devenu un étudiant passionné de l'optimisation des performances d'Oracle APEX et que je pensais simplement partager certaines des choses que j'ai apprises au fil des ans.Comment identifier un goulot d'étranglement?
Il y a beaucoup de choses auxquelles vous voudrez faire attention lors de l'évaluation des performances de votre application. Vous voudrez considérer les problèmes qui lui sont associés, le navigateur. Problèmes de réseau. Configuration ORDS. Configuration de la base de données, y compris les éventuels index manquants. Y a-t-il des verrous de base de données dans le jeu? Attentes?Dès que vous estimez que votre infrastructure sous-jacente est en bon état et n'est pas en faute, il est peut-être temps de porter votre attention sur l'application elle-même, en tenant compte de votre frontend (Javascript et CSS) et de votre backend (SQL et PL / SQL).1. Frontend: l'ordre des fichiers est important
Tout d'abord, si vous incluez des composants CSS et JS personnalisés, assurez-vous que votre CSS est en haut de la page et que JavaScript est en bas .Cela garantit que vos utilisateurs obtiennent au moins les composants de l'interface utilisateur, même si certains fichiers de logique métier ne sont pas déjà chargés.2. Afficher le moniteur d'activité
C'est toujours un excellent endroit pour commencer. Si tout semble lent et que vous ne savez pas où chercher, le moniteur d'activité dans l'environnement de développement APEX peut fournir des informations précieuses.
Lien vers le moniteur d'activité à partir de la console de développement APEX
Chaque page vue de votre espace de travail et de vos applications est enregistrée, y compris des informations sur l'utilisateur, l'horodatage, l'application, l'ID de page et, surtout, l'heure à laquelle l'application s'exécutait.Mon rapport de consultation de page préféré est «Selon les performances des pages pondérées».
Voir l'exemple du moniteur d'activité APEX
Portez une attention particulière à toutes les pages qui ont un grand nombre d'événements de page (ce qui signifie fréquemment visité), et la valeur élevée de la durée d'exécution moyenne de l'application. Il me semble que Joel Kalman a dit un jour que tout ce qui dépassait 0,5 seconde devait être revu. Bien sûr, ceci est une généralisation plutôt grossière et peut (non) se rapporter à votre cas spécifique d'utilisation d'APEX.Le moniteur d'activité facilite le travail avec IR, mais si vous avez besoin d'un peu plus de détails et que vous souhaitez exécuter des rapports dans différents espaces de travail, vous pouvez utiliser la requête suivante dans SQL Developer pour la rendre aussi détaillée que possible: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. Variable de recherche # TIMING #
Vous avez donc peut-être trouvé une page lente. Et maintenant?Eh bien, vous pouvez utiliser la variable de recherche # TIMING # dans le pied de page de vos régions de rapport si vous souhaitez récupérer et afficher leur temps écoulé. Cela peut vous aider à identifier les zones les plus lentes du rapport sur la page sur lesquelles vous pouvez tourner votre attention. Ceci est particulièrement utile sur les pages de tableau de bord où vous pouvez avoir beaucoup de travail.
Utiliser la ligne de substitution # TIMING # dans le pied de page du rapport L'exécution du rapport donnera alors le résultat:
Une chose que j'aime dans cette fonction n'est pas nécessairement qu'elle détermine quelles régions prennent beaucoup de temps à exécuter (je pourrais l'obtenir de mon fenêtres de débogage, voir ci-dessous), mais il offre des informations aux utilisateurs finaux.Souvent, je trouve qu'ils demanderont des données dont je sais qu'elles seront visualisées pendant des âges. À tout le moins, cela leur donne une idée de ce qui pourrait arriver et pourquoi ils ont dû attendre un peu plus longtemps pour leur page que prévu.4. Exécutez la page en mode débogage
Mieux encore, exécutez-le dans Debug LEVEL9 pour accéder au plan d'exécution de votre rapport.La fenêtre de débogage vous montrera tout ce qui se passe sur votre page, et elle montrera le temps d'exécution pour chaque composant. LEVEL9 générera des tonnes de lignes, mais vous pouvez les trier par ordre décroissant de temps pour montrer que votre page prend le plus de temps à s'afficher.5. Méfiez-vous d'appeler v (")
Si vous trouvez un rapport peu performant, vous pouvez vérifier si vous avez utilisé la notation v (”) lorsque vous pouviez utiliser la variable de liaison.select task_name
from tasks
where assigned_to=:APP_USER
ouselect task_name
from tasks
where assigned_to=v('APP_USER')
Dans un grand tableau, la différence entre les deux instructions peut être énorme, car v (”) est en fait un appel de fonction. Cela signifie que vous ne profiterez d'aucun index et que la requête entraînera une analyse complète de la table.Astuce: si vous devez référencer l'état d'une session APEX dans une vue (où vous ne pouvez pas utiliser de variables de liaison), envisagez d'utiliser une sous-requête scalaire qui peut fonctionner presque aussi bien que votre variable de liaison. Voir:select task_name
from tasks
where assigned_to = (select v('APP_USER') from dual)
Merci à John Scott de l'avoir offert à l'un des événements auxquels j'ai assisté.6. Évitez la substitution de chaînes dans les requêtes, si possible
Méfiez-vous des chaînes de recherche dans les requêtes.Considérez, par exemple, une situation dans laquelle vous pourriez avoir besoin d'un décodage ou d'une instruction case dans une requête pour déterminer la page à laquelle vous souhaitez créer une branche: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
Utilisation de la variable de liaison: SESSION, pas la chaîne de recherche & SESSION. peut faire une énorme différence et faire gagner beaucoup de temps à Oracle. La version de variable de liaison permet à Oracle de réutiliser la requête.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 vous souhaitez en savoir plus à ce sujet, consultez la magnifique vidéo de Jorge Rimblas sur les chaînes génériques, les variables de liaison et les liens APEX.7. Utilisez des paramètres déclaratifs dans vos conditions lorsque cela est possible
Lorsque vous utilisez des conditions sur des composants de page, utilisez toujours des paramètres déclaratifs dans la mesure du possible. Ils seront beaucoup plus efficaces.8. Utilisez les paramètres de pagination de manière rationnelle
Dans les rapports volumineux, les options de pagination sélectionnées peuvent avoir un effet significatif. Malgré le fait que depuis la version 18.1 APEX a considérablement amélioré le traitement de pagination (lire ce merveilleux article de Karsten Charsky), vous pouvez désactiver le paramètre "plage de lignes de X à Y de Z" dans l'un d'eux si vous avez des problèmes de performances dans un très gros rapport.9. Évitez le HTML dans les requêtes et utilisez une expression HTML
Lorsque cela est possible, utilisez l'attribut d'expression HTML pour les colonnes du rapport pour inclure tous les attributs HTML / CSS dont vous pourriez avoir besoin.10.
Ainsi, vous avez identifié une zone de rapport très lente que vous avez configurée le mieux possible.Dois-je mettre à jour les données chaque fois que je consulte la page? Pensez aux rapports du tableau de bord, en particulier les données de vente, etc. Même les données de transaction reçues il y a 1 minute peuvent être assez complètes dans de nombreux cas.Si c'est le cas, vous pouvez utiliser l'option de mise en cache de région.
Paramètres de cache du serveur dans les régions APEX.Par défaut, la mise en cache est désactivée, mais si vous l'activez, vous pouvez sélectionner l'option de délai d'expiration du cache, en commençant par seulement 10 secondes. Même 10 secondes aideront les performances du tableau de bord, qui est utilisé par un grand nombre d'utilisateurs! Et il est évident que l'augmentation de ce paramètre aidera encore plus.Attention, si vous avez des données sensibles qui dépendent de l'utilisateur, vous pouvez sélectionner les options "cache par utilisateur" ou même "cache par session".
Paramètres disponibles lors de l'activation de la mise en cache régionaleSi vous décidez d'activer la mise en cache, vous pouvez informer vos utilisateurs de la dernière mise à jour des données. Si tel est le cas, vous pouvez utiliser la fonction APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE .11. Déplacer PL / SQL vers des packages
Assurez-vous de déplacer le code vers des packages. Ils sont déjà compilés dans la base de données, ce qui signifie qu'il y aura moins de frais généraux pour l'analyse dynamique.Vos processus de page doivent être uniquement des appels de package dans la mesure du possible.Stephen Feuerstein a écrit un article très détaillé sur l'écriture PL / SQL pour Oracle Application Express , que vous voudrez peut-être lire. Elle a déjà plusieurs années, mais elle est toujours d'actualité!12. Lancez Advisor!
Je vois rarement des gens utiliser cette fonctionnalité géniale, mais c'est quelque chose que nous devrions tous faire régulièrement. Chaque fois, je me demande ce qu'il trouve d'autre.13. Utilisez les options de construction pour désactiver et activer les composants
Eh bien, vous avez essayé TOUTES CES CHOSES, mais toujours bloqué, ce n'est pas clair sur quoi. Si vous voulez «redessiner votre page», vous devriez envisager d'utiliser des options de construction pour les différents composants de votre page.Ne posez pas de conditions indéfinies sur les composants, sinon vous perdrez toutes vos précieuses conditions! De plus, les composants perpétuels ont la caractéristique désagréable de vivre éternellement dans vos applications ...Créez un nouveau paramètre de construction à l' aide de Status: Exclude.Appliquez-le alternativement aux différents composants de votre page. Commencez votre page à chaque changement et voyez si cela fonctionne mieux. Si votre page s'exécute soudainement plus rapidement, vous avez peut-être trouvé les coupables.14. Comprenez comment divers paramètres IR peuvent affecter les performances APEX.
Avec un rapport interactif mal exécuté, divers réglages, paramètres ou filtres appliqués par vos utilisateurs peuvent exacerber le mauvais travail (oui, c'est vraiment le cas).Comme mentionné précédemment, il est préférable de commencer par utiliser le mode de débogage LEVEL9 et de configurer une véritable requête distincte. Examinez le plan d'exécution, examinez les index, ajustez si possible. N'oubliez pas que chaque vue (tableau, regroupement, graphique, résumé) est une requête distincte qui peut nécessiter une personnalisation. Ensuite, il change à nouveau lorsque vous utilisez le filtre de recherche ou le filtre d'en-tête de colonne!Votre paramètre MaxRowCount entre également en jeu, et vous devez essayer de le rendre aussi petit que possible. Il n'y a pas de bonne réponse à cela, et vous devrez peut-être jouer avec des numéros différents avant d'obtenir quelque chose qui fonctionne pour vos utilisateurs.Fondamentalement, envisagez de supprimer ou de modifier certains scénarios de comportement par défaut. Les développeurs disposent de nombreux contrôles en ce qui concerne les fonctionnalités activées pour les utilisateurs. Il vaut la peine d'essayer divers paramètres et n'oubliez pas de consulter vos utilisateurs pour vous assurer que vous comprenez parfaitement leurs exigences.Enfin, si vous trouvez que votre IR est encore trop lent, vous pouvez envisager 2 alternatives:- Fonctions de table de pipeline (sélectionnez * dans la table (my_rpt_pipelined)) -> elles peuvent fonctionner beaucoup mieux dans les requêtes complexes.
- Générer un rapport de collecte (APEX_COLLECTION)
Merci à Karen Cannell pour ces conseils IR très utiles.15. Trace
Lorsque tout le reste échoue, vous pouvez ajouter "& p_trace = YES" à la fin de votre URL pour créer un fichier de trace que vous pouvez analyser à l'aide de l'utilitaire TKPROF.Vous trouverez plus d'informations sur le traçage SQL ici .Toujours coincé? Je suis toujours étonné de la réactivité de la communauté Oracle APEX . Donnez un coup de main, demandez de l'aide sur divers forums ou sur Twitter, quelqu'un vous orientera certainement dans la bonne direction. J'ai reçu d'innombrables réponses à des appels à l'aide. Vous trouverez la réponse! N'oubliez pas: ce n'est pas l'APEX, c'est le plus souvent vous, vous-même :-)