[MGNLPER-60] Investigate performance of periscope and potential mitigations Created: 01/Nov/18  Updated: 22/Nov/18  Resolved: 22/Nov/18

Status: Closed
Project: Periscope
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Neutral
Reporter: Antti Hietala Assignee: Cedric Reichenbach
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones MGNLPER-59 Check performance of periscope, limit... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Documentation update required:
Yes
Epic Link: Periscope back-end MVP
Sprint: Basel 160
Story Points: 5

 Description   

User story:

I have around 300k stories in the Stories app. They are stored in the JCR. Have you tested Find Bar with these amounts? (real question from a partner)

Test Periscope/Find Bar performance with 300k+ content items. Generate stories, tours and assets. Run searches and time the responses.

Background: Periscope search might be (too) slow as soon as we start dealing with more data, that is, many suppliers and many results per supplier. We should make sure that overall response time of a search stays within acceptable bounds - which should be at the magnitude of ~0.1 seconds to feel instantaneous for the user, or at least sub-second.

  • Check the performance of Periscope when dealing with reasonably large data
  • Limit the maximum number of items listed per supplier (e.g. 5 items) and as many suppliers as to be expected in a typical customer setup.

Acceptance criteria:

  • Response time stays under 1 second.
  • Come up with mitigations for found bottlenecks and either directly apply them or create follow-up tickets.
  • Propose recommendations on how clients should set up search indexing for good performance.
    • When/with how many items is Jackrabbit/Lucene search OK?
    • When/with how many items is Solr needed?
    • How to configure Find Bar / Periscope for optimal performance?

Generated at Mon Feb 12 10:28:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.