Améliorer les performances des requêtes sur AEM

Dans la plupart des anciennes applications qui possèdent une fonctionnalité de recherche, ou de manière plus générale qui font appel à des requêtes côté back, vous pouvez avoir des indexes de requêtes déjà existants. Le plus souvent, ceux-ci nécessitent une optimisation afin de fonctionner plus efficacement. Cet article montre comment convertir les anciens indexes Lucene en indexes de propriété Oak afin de diviser de 3 à 6 fois le temps d’exécution des requêtes.

CONTEXTE DU PROBLEME

Pour notre exemple, nous examinerons un cas concret que vous pourriez rencontrer avec un index lucene. Ici, cet index a été créé pour indexer les traductions de l’adaptateur Globalink de Translation.com.

2 problèmes peuvent survenir :
– L’indexation a échoué / a été corrompue, ce qui entraîne les résultats de la recherche à ne pas afficher les nouvelles soumissions ajoutées.
– Une lenteur d’affichage de l’écran des traductions due aux performances de la requête

SOLUTIONS

Solution intermédiaire
Comme solution intermédiaire, l’index lucene a été désactivé en mettant la valeur de la propriété « type » à « disabled » (cf l’image ci-dessous), cela corrige le problème d’affichage de résultats obsolètes.

Cependant, vous devriez voir apparaître des alertes dans les logs de cette forme :

23.08.2019 17:14:15.942 WARN [127.0.0.1 [1558624454569] POST /libs/settings/granite/operations/diagnosis/granite_queryperformance.explain.json HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor Traversed 58000 nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where [cqIdentifier] is not null and isdescendantnode(a, '/libs/globallink-adaptor/submissions') order by [dateCreated] desc /* xpath: /jcr:root/libs/globallink-adaptor/submissions//[(@cqIdentifier)] order by @dateCreated descending */, path=/libs/globallink-adaptor/submissions//, property=[cqIdentifier=[is not null]]); consider creating an index or changing the query

DIAGNOSTIC ET OUTILS D’ANALYSE

– des requêtes aussi lentes devraient être remontées dans les outils de diagnostic d’AEM sous « Query Performance »
– grâce à l’alerte et l’outil de performance de requête, vous devriez les voir sous ‘Slow Queries’/’Popular Queries’ et ainsi être en mesure de comprendre la requête effectuée. Dans notre case : ‘/jcr:root/libs/globallink-adaptor/submissions//*[(@cqIdentifier)] order by @dateCreated descending’

– à partir de cette requête vous pouvez maintenant créer un index de propriété Oak

SOLUTION

Vous devez créer un index de propriété OAK basé sur la requête comme dans l’image ci-dessous

AMELIORATION DE PERFORMANCE OBSERVÉE PERFORMANCE DE REQUETE

– Performance avec l’ancien index Lucene :  »heuristics »: { « count »: 1784, « countTime »: 370, « executionTime »: 2, « getNodesTime »: 263, « totalTime »: 635}
– Performance après désactivation de l’index lucene :  »heuristics »: { « count »: 1784, « countTime »: 1411, « executionTime »: 1, « getNodesTime »: 1408, « totalTime »: 2820 }
– Performance après avoir ajouté l’index de propriété : « heuristics »: { « count »: 1784, « countTime »: 53, « executionTime »: 1, « getNodesTime »: 51, « totalTime »: 105 }
Comme vous pouvez le constater à partir des résultats ci-dessus, le temps d’exécution de la requête a été divisé entre 3 et 6 fois.
Les détails mentionnés ci-dessus sont rassemblés dans la section « Expliquer la requête » de la console « Performances de la requête ».

Article original : https://forknowledgeandwisdom.com/blog/f/optimisation-of-lucene-index-by-replacing-with-oak-property-index

Article traduit par Valtech

Par Vikas Chandran