Felsöka långsamma frågor

Långsam frågeklassificering

Det finns tre huvudklassificeringar av långsamma frågor i AEM, ordnade efter allvarlighetsgrad:

  1. Indexlösa frågor

    • Frågor som gör det not omvandla till ett index och gå igenom JCR-innehållet för att samla in resultat

  2. Dåligt begränsade (eller begränsade) frågor

    • Frågor som leder till ett index, men som måste gå igenom alla indexposter för att samla in resultat

  3. Stora resultatuppsättningsfrågor

    • Frågor som returnerar mycket många resultat

De första två klassificeringarna av frågor (indexlösa och dåligt begränsade) är långsamma eftersom de tvingar Oak-frågemotorn att granska varje potentiell resultat (innehållsnod eller indexpost) för att identifiera vilken som tillhör faktisk resultatuppsättning.

Att inspektera varje möjligt resultat kallas att gå igenom.

Eftersom varje potentiellt resultat måste kontrolleras, växer kostnaden för att fastställa det faktiska resultatet linjärt med antalet potentiella resultat.

Genom att lägga till frågebegränsningar och justera index kan indexdata lagras i ett optimerat format som ger snabb resultathämtning och minskar eller eliminerar behovet av linjär kontroll av potentiella resultatuppsättningar.

I AEM 6.3 misslyckas frågan som standard när en genomgång på 100 000 nås och ett undantag genereras. Den här gränsen finns inte som standard i AEM versioner före AEM 6.3, men den kan anges med hjälp av APache Jackrabbit Query Engine Settings OSGi-konfigurationen och QueryEngineSettings JMX-böna (egenskapen LimitReads).

Identifiera indexlösa frågor

Under utveckling

Förklara alla frågor och kontrollera att deras frågeplaner inte innehåller /* bläddra förklaringar i dem. Exempel på genomgång av frågeplan:

  • PLAN: [nt:unstructured] as [a] /* traverse "/content//*" where ([a].[unindexedProperty] = 'some value') and (isdescendantnode([a], [/content])) */

Efter distribution

  • Övervaka error.log för indexlösa genomgångsfrågor:

    • *INFO* org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without index) ... ; consider creating and index
    • Det här meddelandet loggas bara om det inte finns något index tillgängligt och om frågan eventuellt går igenom många noder. Meddelanden loggas inte om ett index är tillgängligt, men mängden att gå igenom är liten och därmed snabb.

  • Besök AEM Frågeprestanda driftskonsol och Förklara långsamma frågor som letar efter stegvis genomgång eller inga indexfrågeförklaringar.

Identifierar dåligt begränsade frågor

Under utveckling

Förklara alla frågor och kontrollera att de matchar ett index som justerats för att matcha frågans egenskapsbegränsningar.

  • Idealisk frågeplantäckning har indexRules för alla egenskapsbegränsningar och minst för de tätaste egenskapsbegränsningarna i frågan.
  • Frågor som sorterar resultat bör matchas till ett Lucene-egenskapsindex med indexregler för de sorterade efter egenskaper som anges orderable=true.

Som standard cqPageLucene har ingen indexregel för jcr:content/cq:tags

Innan indexregeln cq:tags läggs till

  • cq:taggindexregel

    • Finns inte i lådan

  • Fråga i Frågebyggaren

    type=cq:Page
property=jcr:content/cq:tags
property.value=my:tag

  • Frågeplan

    [cq:Page] as [a] /* lucene:cqPageLucene(/oak:index/cqPageLucene?lang=sv) *:* where [a].[jcr:content/cq:tags] = 'my:tag' */

Den här frågan löses till cqPageLucene index, men eftersom det inte finns någon egenskapsindexregel för jcr:content eller cq:tags, när den här begränsningen utvärderas, alla poster i cqPageLucene index kontrolleras för att fastställa en matchning. Det innebär att om indexet innehåller 1 miljon cq:Page noder kontrolleras sedan 1 miljon poster för att fastställa resultatet.

När indexregeln cq:tags lagts till

  • cq:taggindexregel

    /oak:index/cqPageLucene/indexRules/cq:Page/properties/cqTags
@name=jcr:content/cq:tags
@propertyIndex=true

  • Fråga i Frågebyggaren

    type=cq:Page
property=jcr:content/cq:tags
property.value=myTagNamespace:myTag

  • Frågeplan

    [cq:Page] as [a] /* lucene:cqPageLucene(/oak:index/cqPageLucene?lang=sv) jcr:content/cq:tags:my:tag where [a].[jcr:content/cq:tags] = 'my:tag' */

Tillägget av indexRule för jcr:content/cq:tags i cqPageLucene index tillåter cq:tags data som ska lagras på ett optimerat sätt.

När en fråga med jcr:content/cq:tags begränsning utförs, indexet kan söka efter resultat efter värde. Det betyder att om 100 cq:Page noder har myTagNamespace:myTag som värde returneras endast de 100 resultaten och de andra 999 000 utesluts från begränsningskontrollerna, vilket förbättrar prestandan med en faktor på 10 000.

Ytterligare frågebegränsningar minskar förstås antalet giltiga resultatuppsättningar och optimerar frågeoptimeringen ytterligare.

Utan en extra indexregel för cq:tags -egenskap, även fulltextfråga med en begränsning för cq:tags skulle fungera dåligt eftersom resultatet från indexet skulle returnera alla fulltextmatchningar. Begränsningen för cq:tags filtreras efter den.

En annan orsak till postindexfiltrering är Access Control Lists, som ofta missas under utvecklingen. Försök att se till att frågan inte returnerar sökvägar som kanske inte är tillgängliga för användaren. Detta kan oftast göras genom bättre innehållsstruktur tillsammans med relevant sökvägsbegränsning för frågan.

Ett praktiskt sätt att identifiera om Lucene-indexet returnerar många resultat för att returnera en mycket liten delmängd som frågeresultat är att aktivera DEBUG-loggar för org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex och se hur många dokument som läses in från indexet. Antalet slutliga resultat jämfört med antalet inlästa dokument bör inte vara oproportionerligt. Mer information finns i Loggning.

Efter distribution

  • Övervaka error.log för genomgångsfrågor:

    • *WARN* org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed ### nodes ... consider creating an index or changing the query

  • Besök AEM Frågeprestanda driftskonsol och Förklara långsamma frågor som söker efter frågeplaner som inte löser frågeegenskapsbegränsningar till indexegenskapsregler.

Identifiera stora resultatuppsättningsfrågor

Under utveckling

Ange låga tröskelvärden för oak.queryLimitInMemory (t.ex. 10000) och oak.queryLimitReads (t.ex. 5000) och optimera den dyra frågan när du klickar på ett UnsupportedOperationException som säger"Frågan läser fler än x noder…".

Detta hjälper till att undvika resurskrävande frågor (t.ex. som inte backas upp av något index eller backas upp av mindre täckande index). En fråga som till exempel läser 1M-noder skulle leda till mycket IO och negativt påverka programmets prestanda. Alla frågor som inte godkänns på grund av ovanstående gränser bör därför analyseras och optimeras.

Efter distribution

  • Övervaka loggarna för frågor som utlöser genomgång av stora noder eller stor minnesförbrukning i stackar: "

    • *WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
    • Optimera frågan för att minska antalet genomgående noder

  • Övervaka loggarna för frågor som utlöser stor minnesförbrukning i stackar:

    • *WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
    • Optimera frågan för att minska heap-minnesanvändningen

I AEM 6.0-6.2 kan du justera tröskelvärdet för nodgenomgång via JVM-parametrar i AEM startskript för att förhindra att stora frågor överbelastar miljön. Rekommenderade värden är:

  • -Doak.queryLimitInMemory=500000
  • -Doak.queryLimitReads=100000

I AEM 6.3 är ovanstående två parametrar förkonfigurerade som standard och kan ändras via OSGi QueryEngineSettings.

Mer information finns under: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits

Justering av frågeprestanda

Motto för optimering av frågeprestanda i AEM är:

"Ju fler begränsningar, desto bättre."

Följande utkast rekommenderar justeringar för att säkerställa frågeprestanda. Finjustera först frågan, en mindre diskret aktivitet och finjustera sedan indexdefinitionerna om det behövs.

Justera frågeuttryck

AEM stöder följande frågespråk:

  • Query Builder
  • JCR-SQL2
  • XPath

I följande exempel används Query Builder som det vanligaste frågespråket som används av AEM utvecklare, men samma principer gäller för JCR-SQL2 och XPath.

  1. Lägg till en nodetypbegränsning så att frågan löses till ett befintligt Lucene-egenskapsindex.

  • Ooptimerad fråga

    property=jcr:content/contentType
property.value=article-page

  • Optimerad fråga

    type=cq:Page
property=jcr:content/contentType
property.value=article-page

    Frågor som saknar begränsningskraft för nodetype AEM att anta nt:base nodetype, som alla noder i AEM är en undertyp till, vilket i sin tur resulterar i ingen nodtypsbegränsning.

    Inställning type=cq:Page begränsar frågan till endast cq:Page noder och löser frågan till AEM cqPageLucene, vilket begränsar resultatet till en delmängd av noder (endast cq:Page noder) i AEM.

  1. Justera frågans nodetypbegränsning så att frågan matchar ett befintligt Lucene-egenskapsindex.

  • Ooptimerad fråga

    type=nt:hierarchyNode
property=jcr:content/contentType
property.value=article-page

  • Optimerad fråga

    type=cq:Page
property=jcr:content/contentType
property.value=article-page

    nt:hierarchyNode är den överordnade nodtypen för cq:Pageoch förutsätter jcr:content/contentType=article-page används endast för cq:Page noder via vårt anpassade program returnerar den här frågan endast cq:Page noder där jcr:content/contentType=article-page. Detta är dock en suboptimal begränsning eftersom:

    • Annan nod ärver från nt:hierarchyNode (t.ex. dam:Asset) som lägger till i onödan till de potentiella resultaten.
    • Det finns inget AEM-angivet index för nt:hierarchyNode, men som det finns ett angivet index för cq:Page.

    Inställning type=cq:Page begränsar frågan till endast cq:Page noder och löser frågan till AEM cqPageLucene, vilket begränsar resultatet till en delmängd av noder (endast cq:Page-noder) i AEM.

  1. Du kan också justera egenskapsbegränsningar så att frågan matchar ett befintligt egenskapsindex.

  • Ooptimerad fråga

    property=jcr:content/contentType
property.value=article-page

  • Optimerad fråga

    property=jcr:content/sling:resourceType
property.value=my-site/components/structure/article-page

    Ändra egenskapsbegränsningen från jcr:content/contentType (ett anpassat värde) till den välkända egenskapen sling:resourceType låter frågan matcha egenskapsindexet slingResourceType som indexerar allt innehåll med sling:resourceType.

    Egenskapsindex (till skillnad från Lucene-egenskapsindex) används bäst när frågan inte identifieras av nodetype, och en enskild egenskapsbegränsning dominerar resultatuppsättningen.

  1. Lägg till den striktaste möjliga sökvägsbegränsningen för frågan. Använd /content/my-site/us/en över /content/my-site, eller /content/dam över /.

  • Ooptimerad fråga

    type=cq:Page
path=/content
property=jcr:content/contentType
property.value=article-page

  • Optimerad fråga

    type=cq:Page
path=/content/my-site/us/en
property=jcr:content/contentType
property.value=article-page

    Omfång för sökvägsbegränsningen från path=/contenttill path=/content/my-site/us/en gör att indexen kan minska antalet indexposter som behöver inspekteras. När frågan kan begränsa sökvägen mycket bra, bortom bara /content eller /content/dam, kontrollera att indexet har evaluatePathRestrictions=true.

    Anteckning med evaluatePathRestrictions ökar indexstorleken.

  1. Undvik om möjligt frågefunktioner och -åtgärder som: LIKE och fn:XXXX när kostnaderna skalas upp med antalet begränsningsbaserade resultat.

  • Ooptimerad fråga

    type=cq:Page
property=jcr:content/contentType
property.operation=like
property.value=%article%

  • Optimerad fråga

    type=cq:Page
fulltext=article
fulltext.relPath=jcr:content/contentType

    Villkoret LIKE tar lång tid att utvärdera eftersom inget index kan användas om texten börjar med ett jokertecken ("%…"). jcr:contains-villkoret tillåter att ett fulltextindex används och är därför att föredra. Detta kräver att det matchade Lucene-egenskapsindexet har indexRule för jcr:content/contentType med analayzed=true.

    Använda frågefunktioner som fn:lowercase(..) kan vara svårare att optimera eftersom det inte finns snabbare motsvarigheter (utanför mer komplexa och diskreta indexanalysatorkonfigurationer). Det är bäst att identifiera andra omfångsbegränsningar för att förbättra den övergripande frågeprestandan, vilket kräver att funktionerna arbetar på den minsta möjliga uppsättningen möjliga resultat.

  1. Justeringen är Query Builder-specifik och gäller inte JCR-SQL2 eller XPath.

    Använd Query Builder' gissningssumma när alla resultat är not omedelbart behövs.

    • Ooptimerad fråga

      type=cq:Page
path=/content

    • Optimerad fråga

      type=cq:Page
path=/content
p.guessTotal=100

    Om frågekörningen är snabb men antalet resultat är stort, s. guessTotal är en viktig optimering för frågor i Query Builder.

    p.guessTotal=100 anger för Query Builder att endast samla in de första 100 resultaten och anger en boolesk flagga som anger om det finns minst ett resultat till (men inte hur många fler, eftersom det skulle bli långsamt om talet räknades). Den här optimeringen är utmärkt för sidnumrering eller oändlig inläsning, där bara en delmängd av resultaten visas stegvis.

Justering av befintligt index

  1. Om den optimala frågan löses till ett egenskapsindex finns det inget kvar att göra eftersom egenskapsindex är minimalt justeringsbara.

  2. Annars bör frågan matchas mot ett Lucene-egenskapsindex. Om inget index kan tolkas går du till Skapa ett nytt index.

  3. Konvertera frågan till XPath eller JCR-SQL2 efter behov.

    • Fråga i Frågebyggaren

      query type=cq:Page
path=/content/my-site/us/en
property=jcr:content/contentType
property.value=article-page
orderby=@jcr:content/publishDate
orderby.sort=desc

    • XPath genererad från frågan i Query Builder

      /jcr:root/content/my-site/us/en//element(*, cq:Page)[jcr:content/@contentType = 'article-page'] order by jcr:content/@publishDate descending

  4. Ange XPath (eller JCR-SQL2) till Definitionsgenerator för Oak Index för att generera den optimerade definitionen av Lucene-egenskapsindex.

    Skapad definition av Lucene-egenskapsindex

    - evaluatePathRestrictions = true
- compatVersion = 2
- type = "lucene"
- async = "async"
- jcr:primaryType = oak:QueryIndexDefinition
    + indexRules
    + cq:Page
        + properties
        + contentType
            - name = "jcr:content/contentType"
            - propertyIndex = true
        + publishDate
            - ordered = true
            - name = "jcr:content/publishDate"

  5. Sammanfoga manuellt den genererade definitionen i det befintliga Lucene-egenskapsindexet på ett additivt sätt. Var försiktig så att du inte tar bort befintliga konfigurationer eftersom de kan användas för att tillgodose andra frågor.

    1. Leta reda på det befintliga Lucene-egenskapsindex som omfattar cq:Page (med hjälp av Indexhanteraren). I detta fall /oak:index/cqPageLucene.
    2. Identifiera konfigurationsförändringen mellan den optimerade indexdefinitionen (steg 4) och det befintliga indexet (/oak:index/cqPageLucene?lang=sv) och lägg till de saknade konfigurationerna från det optimerade indexet till den befintliga indexdefinitionen.
    3. Enligt AEM bästa praxis för omindexering är det antingen en uppdatering eller omindexering i ordning, baserat på om befintligt innehåll kommer att påverkas av den här indexkonfigurationsändringen.

Skapa ett nytt index

  1. Kontrollera att frågan inte matchar ett befintligt Lucene-egenskapsindex. Om så är fallet, se avsnittet ovan om justering och befintligt index.

  2. Konvertera frågan till XPath eller JCR-SQL2 efter behov.

    • Fråga i Frågebyggaren

      type=myApp:Author
property=firstName
property.value=ira

    • XPath genererad från frågan i Query Builder

      //element(*, myApp:Page)[@firstName = 'ira']

  3. Ange XPath (eller JCR-SQL2) till Definitionsgenerator för Oak Index för att generera den optimerade definitionen av Lucene-egenskapsindex.

    Skapad definition av Lucene-egenskapsindex

    - compatVersion = 2
- type = "lucene"
- async = "async"
- jcr:primaryType = oak:QueryIndexDefinition
    + indexRules
    + myApp:AuthorModel
        + properties
        + firstName
            - name = "firstName"
            - propertyIndex = true

  4. Distribuera den genererade indexdefinitionen för Lucene-egenskap.

    Lägg till XML-definitionen från Oak Index Definition Generator för det nya indexet i det AEM projektet som hanterar Oak-indexdefinitioner (kom ihåg att behandla Oak-indexdefinitioner som kod, eftersom koden är beroende av dem).

    Distribuera och testa det nya indexet efter den vanliga AEM programutvecklingslivscykeln och kontrollera att frågan löses till indexvärdet och att frågan är utförd.

    När det här indexet börjar distribueras kommer AEM att fylla i indexet med nödvändiga data.

När är det okej med indexlösa frågor och genomgående frågor?

På grund av AEM flexibla innehållsarkitekturen är det svårt att förutsäga och se till att genomgången av innehållsstrukturer inte förändras över tid och blir oacceptabla.

Se därför till att ett index uppfyller frågor, förutom om kombinationen av sökvägsbegränsning och nodetype-begränsning garanterar att färre än 20 noder genomgås någonsin.

Frågeutvecklingsverktyg

Adobe stöds

Community-stöd

  • Definitionsgenerator för Oak Index

    • Generera ett optimalt Lucence-egenskapsindex från XPath- eller JCR-SQL2-frågesatser.

  • AEM Chrome-plugin

    • Webbläsartillägget Google Chrome som visar loggdata per begäran, inklusive utförda frågor och tillhörande frågeplaner, i webbläsarens Dev Tools Console.
    • Kräver Sling Log Tracer 1.0.2+ som ska installeras och aktiveras på AEM.

På denna sida