Timeouts when searching with a query "Works"

[jimman2003]

Evidence / Screenshot (if possible)

Relevant url?

https://openlibrary.org/search?q=Works&mode=everything

Steps to Reproduce

1. Go to the above link
2. Observe the error

• Actual: Timeout on Search
• Expected: Show results

Details

• Logged in (Y/N)?
  Y
• Browser type/version?
  Brave/Chromium 91
• Operating system?
  Linux
• Environment (prod/dev/local)? prod

Prod

Proposal & Constraints

Related files

Stakeholders

[jimman2003]

interestingly enough other bigger queries work fine

[mekarpeles]

This happens with many common words related to #7271 the current search page flow which synchronously fetches search results and facets (which we are trying to tease apart into 2 separate stages -- search results that load synchronously and facets that load async.

[cdrini]

Took a moment to investigate one option here, which is solr's support for inexact counts: https://solr.apache.org/guide/solr/latest/query-guide/common-query-parameters.html#minexactcount-parameter . Unfortunately it seemed to make the query a little slower, somehow. /solr/openlibrary/select?indent=true&minExactCount=1000&q.op=OR&q=text%3Abooks+AND+type%3Awork&useParams=&wt=json . So that is likely not enough.

[tfmorris]

It works for me returning 616 251 résultats, but the facet sidebar renders as "undefined."

which we are trying to tease apart into 2 separate stages -- search results that load synchronously and facets that load async

but that doesn't save any of the work -- and when the query times out, as it does in this case, all that work is wasted. I would argue that facets are rarely used and, as such, they should be rendered collapsed by default and only populated when they are expanded by the user, individually, not all together.

It also looks like highlighting is turned on, which is another expensive operation.