[COMPASS-1766] Investigate Compass CRUD render times with increasing numbers of keys Created: 21/Aug/17  Updated: 27/Oct/23  Resolved: 01/Oct/18

Status: Closed
Project: Compass
Component/s: CRUD, Performance
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Peter Schmidt Assignee: Unassigned
Resolution: Gone away Votes: 0
Labels: stagnant
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: COMPASS-1739
Story Points: 2

 Description   
  1. Use the script on COMPASS-1764, mgeneratejs or similar to generate documents with 50,100,200,400,800,1600,3200,6400,12800,25000,50000,100000 top-level fields
  2. Report results - Measure time to render and chart it
    1. is it a straight line? is it exponentially slower each time?
    2. is there a cut off point where it just hangs?


 Comments   
Comment by Durran Jordan [ 01/Oct/18 ]

Rewriting stories to remove hadron-document

Comment by Sam Weaver [ 22/Aug/17 ]

thomasr - I'm looking to answer a broader question.

We know that we will significantly increase our value if we are able to be more robust with various large schemas or collections. I think we can all agree that it's a priority for us to work on "handling large documents" and "handling large collections" given feedback from existing customers (Oxford Nanopore, Barclays, Mercedes etc) that Compass is slow to render or hangs. Granted, things have improved in 1.8, but let's see where the threshold for improvement is.

What we don't have a good idea of right now is how large is large? The idea of this ticket is to draw a list of known bounds where we can say "we KNOW that anything over X amount is unusable" of which we can get a better idea of what our potential impact base is.

Absolutely fine with doing a slimmed down version (5 tests) of my initial Slack conversation. I think it'd be a valuable exercise to get that time complexity curve.

Comment by Thomas Rueckstiess [ 22/Aug/17 ]

sam.weaver, you proposed this in Slack. It's going to take at least an engineer day to run all these series and feels like busywork. What are you trying to answer with these tests? Are you looking for time complexity (linear, quadratic, ...) or a cliff or something?

If we go ahead with this ticket, I'd like to reduce it to maybe 5 tests, which should give us an estimate of the shape of the curve, for example 100, 500, 2500, 12500, 62500 (always increase by 5x).

Generated at Wed Feb 07 22:28:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.