Problèmes de performances des requêtes de ressources de gestion des ressources numériques liés aux avertissements de traversée et à une utilisation inefficace des index
Les requêtes de ressources de gestion des ressources numériques de Adobe Experience Manager (AEM) deviennent lentes, expirent ou échouent lorsque des jeux de résultats volumineux, une syntaxe de requête non prise en charge, une sélection d’index inefficace ou des filtres de requête insuffisants provoquent une traversée excessive des nœuds. Le problème affecte les requêtes Query Builder, les requêtes SQL2, les tâches du planificateur, les points d’entrée de l’API et les performances de recherche de ressources de gestion des ressources numériques. Pour résoudre ce problème, optimisez les requêtes, améliorez l’indexation et réduisez le parcours transversal.
Description description
Environnement
Adobe Experience Manager as a Cloud Service (AEMaaCS)
Problème/Symptômes
- Les requêtes expirent ou renvoient* des avertissements « L’index a traversé trop de nœuds »*.
- Les requêtes SQL2 échouent avec des erreurs d’analyse, car Oak transforme la syntaxe LIMIT non prise en charge. Par exemple,
LIMIT 1devientLIMIT(*)1, ce qui entraîne une exception ParseException. - Les points d’entrée de Query Builder renvoient des réponses de panne de service lorsque des chemins DAM volumineux déclenchent des traversées importantes.
- La sortie Expliquer la requête n’indique aucune utilisation d’index et affiche Index utilisés : aucun.
- Les requêtes sur les chemins de gestion des ressources numériques volumineux tels que
/content/dam/...prennent des centaines de secondes ou sont bloquées lorsquep.limit=-1est utilisé.
Cause première
Le problème se produit car les requêtes de gestion des ressources numériques volumineuses sans filtres adéquats forcent Oak à analyser un nombre excessif de nœuds. Syntaxe SQL2 LIMIT/OFFSET non prise en charge, sélection d’index inefficace, conditions non prises en charge telles que IS NULL et ensembles de résultats illimités empêchent une utilisation efficace de l’index. Les hiérarchies de dossiers volumineuses peuvent également entraîner des délais d’expiration HTTP, l’épuisement des ressources et des avertissements de traversée lorsque les requêtes ne sont pas optimisées.
Résolution resolution
Pour identifier le problème de requête et améliorer les performances des requêtes de gestion des ressources numériques, procédez comme suit :
- Identifiez le type d’échec de la requête en examinant les journaux, les résultats du débogueur Query Builder, la sortie des performances de la requête et expliquez les résultats de la requête.
- Réduisez les jeux de résultats volumineux en remplaçant
p.limit=-1par une limite raisonnable et en réduisant la portée de la requête lors de l’interrogation de hiérarchies de gestion des ressources numériques volumineuses. - Remplacez la syntaxe SQL2 LIMIT/OFFSET non prise en charge par une syntaxe prise en charge telle que
OPTION(LIMIT 1)et utilisez la pagination de Query Builder si nécessaire. - Consultez la section Expliquer la sortie de requête et vérifiez que la requête utilise l’index DAM attendu au lieu des index de secours.
- Appliquez la balise d’index appropriée lorsque Expliquer la requête affiche une sélection d’index incorrecte. Par exemple, ajoutez des
option(index tag assetsOmnisearch)si nécessaire. - Supprimez ou restructurez les conditions IS NULL qui empêchent l’utilisation des index et forcent le parcours transversal.
- Divisez les requêtes en sous-requêtes plus petites lorsque la hiérarchie de gestion des ressources numériques contient de très grandes structures de dossiers. Par exemple, divisez les requêtes par sous-dossier au lieu d’interroger un chemin d’accès unique contenant des dizaines de milliers de ressources.
- Ajoutez d’autres filtres de métadonnées tels que la date, le type de ressource ou d’autres propriétés indexées pour réduire le nombre de nœuds analysés et améliorer l’éligibilité de l’index.
- Validez la résolution en exécutant à nouveau la requête, en examinant la sortie Expliquer la requête, en confirmant l’utilisation correcte de l’index et en veillant à ce que les avertissements de traversée et les délais d’expiration ne se produisent plus.
Quand réaffecter
- Les avertissements de parcours se poursuivent après l’application des limites et des filtres de requête.
- Expliquer la requête continue à n’afficher aucune utilisation d’index après l’optimisation des requêtes.
- La syntaxe SQL2 prise en charge échoue toujours une fois la requête corrigée.
- Les points d’entrée de Query Builder continuent de renvoyer des erreurs de panne de service après l’optimisation et la validation des index.