Felsöka långsamma frågor

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

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

Stora resultatuppsättningsfrågor

• Frågor som returnerar mycket många resultat

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.

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.

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.

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.

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.

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

Använd Query Builder' gissningssumma när hela uppsättningen resultat inte ​ behövs omedelbart.

• 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.

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

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

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
  

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"

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 (https://experienceleague.adobe.com/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.

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

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']
  

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

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.