Typing in search bar can be unresponsive

[VWoeltjen]

For a reasonably large set of objects, typing in search bar can be unresponsive after the first one or two characters, particularly if there are a lot of hits for those characters. Unresponsiveness lasts for roughly 1-2s. Subsequent typing gives results more quickly.

Could try throttling the search function using the throttle service.

May also want to do something to wait until previous search results have been returned before initiating a new search.

This was observed using a non-ES data store (so issue may also be specific to GenericSearch)

[VWoeltjen]

Note that by "reasonably large set of objects", I mean roughly 100,000

[larkin]

I've seen this as well.

Is there any chance of lots of DOM nodes being instantiated and tossed?

Or potential portions of the algorithm that are slow-- not linear time?

For comparison, the table view can filter and sort 50k rows with unnoticable latency and there is no throttling occurring. V8 should have no problem working with datasets in the 250,000-1,000,000 record range, but needless DOM operations will quickly trash performance.

Pete

On Aug 28, 2015, at 9:13 AM, Victor Woeltjen <notifications@github.commailto:notifications@github.com> wrote:

For a reasonably large set of objects, typing in search bar can be unresponsive after the first one or two characters, particularly if there are a lot of hits for those characters. Unresponsiveness lasts for roughly 1-2s. Subsequent typing gives results more quickly.

Could try throttling the search functionhttps://github.com/nasa/openmctweb/blob/509badb225ee7f619c29bd886fa56ca462748e03/platform/search/src/controllers/SearchController.js#L132 using the throttlehttps://github.com/nasa/openmctweb/blob/6aaa887e658a91166270de0ab066168d2575f6ed/platform/core/src/services/Throttle.js service.

May also want to do something to wait until previous search results have been returned before initiating a new search.

This was observed using a non-ES data store (so issue may also be specific to GenericSearch)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91.

[slhale]

I tried adding throttle to the search controller, but I don't have a data set as large as 100 000 items to check it out with.

[VWoeltjen]

You could try using Example Taxonomy and increasing the number of "telemetry points" that get instantiated per "subsystem" - see https://github.com/nasa/openmctweb/blob/master/example/taxonomy/src/ExampleTaxonomyModelProvider.js#L47

That said, I am a little suspicious that this may be due to the number of search results that get returned from the worker. The worker is checking for a maxResults property to determine if it should truncate, whereas the provider is passing in a maxNumber property. I think this means that a larger number of results are coming back from the worker.

@larkin has a good point, though, and in general this number shouldn't be daunting. Did a little debugging, and around 7000 domain objects match the first letter of the query. It looks like the observed latency is split just about evenly between garbage collector (40%) and something Angular (40%); the Angular traces aren't particularly informative, but if there's somewhere where a large number of timeouts or promises are occurring that is suspicious.

That said, if we get a working maResults of around 1000 I think this problem won't be observable. Also don't imagine anyone paging through 1000 domain objects any time soon. Looking at the generic search implementation, it looks like results don't get sorted by score until after truncating to maxResults - that would need to change as well so that the 1000 most relevant results are the ones that actually come back from the worker.

[larkin]

@VWoeltjen @slhale Looks like fixes for this have been pushed in open91 but not opened for review & integrate. Is there further development work here necessary or is this ready to be reviewed-- i.e. should we open a pull request? (https://github.com/nasa/openmctweb/compare/open91)

[VWoeltjen]

@larkin Looking over the changes there, I don't think that's ready to merge. The usage of throttle would need to be moved out of the search method, at the very least, but generally speaking I think the issue needs more investigation to understand root causes.

[larkin]

@VWoeltjen I'll put this on my list for follow-up (probably next week).

[larkin]

Resolved with #193.

[RCarvalhoNASA]

Testathon 20151123: typing in the search field still becomes very laggy after the first couple of characters. It's only a couple of seconds, but while I would expect that delay in showing the search results, I wouldn't really expect it for the letters I'm typing. Sample strings include 'bmsio', 'epsio', 'antpt' (which are all used as the start of the name of multiple packets within the RP15 packet structure used in the testathon)

[VWoeltjen]

Reopening based on previous comment.

[larkin]

Will inspect to find causes of slow object instantiation, and if that does not quickly yield an answer, will implement a short term fix such as debounce or only searching on submit.

[charlesh88]

Notes from tagup 10/26/16:

• @larkin: need to be able to cancel requests to the Search service.