[MAGNOLIA-9049] Improve search and findbar performance Created: 10/Aug/23  Updated: 08/Sep/23

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: Neutral
Reporter: Michael Duerig Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-7360 listView and thumbnailView are unusab... Open
relates to ADMINCTR-161 Show visual feedback when searching i... Open
Template:
Epic Name: search performance
Acceptance criteria:
Empty

 Description   

Context

See the notes from UHZ for pain points and initial findings.

Questions for discovery

  • Align with PDI-61 (Find relevant content fast) and identify remaining gaps:
  • Can we speed up permission evaluation within search the way UZH did and evaluate permissions first instead of per item? How far can we generalise the approach if access rights are not fully hierarchical? Is there a good way to optimise queries given a priory knowledge of user permissions? E.g. when permissions are set along sites.
    • MGNLPER-173: JcrSearchResultSupplier should consider users access
      Ticket was closed as "obsolete", should be revaluated.
  • Removing old content from the repository helps speeding up search by reducing bloat (see MAGNOLIA-9057)
  • Offloading / externalising specialised content helps speeding up search by reducing bloat
    • Indexing (i.e. Solr)
    • Version store (MAGNOLIA-9052)
    • Assets (MAGNOLIA-9055)
    • Any content that is non hierarchical and tends to create large numbers of direct child nodes. E.g. content related to logging and record keeping. Such content is generally mostly write once read never.
  • Revisit index configurations and ensure we only index what we need (e.g. do we index versions?)
  • Replace “like” with “contains” in queries where possible. If necessary we can make "contains" the default but leave an option to use contains if explicitly asked for by a user. (A "contains" query should be more efficient than a "like" query but this needs to be quantified before we put too much effort into it).
    • MGNLUI-7755: Ability to improve JCR filtering performance by using STARTSWITH instead of CONTAINS operator
    • MGNLPER-168: JcrSearchResultSupplier generates inefficient queries
    • Above tickets cover assets, same should be evaluated for pages
  • QOM QueryManager is inefficient
    • This needs to be qualified and quantified: what is slow, why and how much?
  • Finding nodes by name is slow since node names are apparently not indexed.
    • Double check, can we adjust the index?
    • Can we use jcrName instead?

Development notes

  • There is an option to log slow queries: magnolia.jcr.query.logging.thresholdMs.  

Generated at Mon Feb 12 04:38:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.