3619: Performace of /api/search poor on large deployments

thom.******@gmai***** (Google Code) (Is this you? Claim this profile.)
chipx86
chipx86
Oct. 23, 2014
What version are you running?

Reviewboard 2.0.3

What's the URL of the page this enhancement relates to, if any?

/api/search

Describe the enhancement and the motivation for it.

With over 100,000 review requests in our DB,  text query of ReviewRequest summary caused by https://github.com/reviewboard/reviewboard/blob/556609d/reviewboard/webapi/resources/search.py#L75 takes a long time for very short strings.

We often see exceptions come in for "/api/search?q=d" or "/api/search?q=r";  The user is typing slower than the 400ms ajaxDelay; presumably they're still typing and want to search for something longer -- they won't even see this first request.

Depending on the deployment, this request can will block other requests from processing, and potentially could trigger 500 responses.

Our deployment is apache mod_proxy to a gunicorn server that times out after 120 seconds.  The gunicorn timeout triggers a SIGABRT, which sends admins unhandled exception for SystemExit(1).  


Maybe could the search optimize to not search summary for very short strings? (<2 or 3 characters)

Or maybe could /api/search leverage the search index if it is present?


What operating system are you using? What browser?

Any.

Please provide any additional information below.

We're using a MySql Database.
chipx86
#1 chipx86
Fixed in 27847cd.

We improved performance by adding a missing index and limiting searches to prefix-based searching. Unfortunately, it means you can't search within the middle of summaries anymore. We're hoping to improve this in the future to use a search index, but we've had some other major complaints of this recently, so we decided to limit it for now.
  • +Fixed
  • +Component-Search
    +Milestone-Release2.0.x
  • +chipx86