Page MenuHomePhabricator

[Task] Cache wbsearchentities responses for short prefixes
Closed, DeclinedPublic

Description

We use prefix searches on the wb_terms table to show type-ahead suggestions in the entity selector widget. These queries are very slow for short prefixes (three or less characters takes about 15 seconds on the live cluster currently).

We should cache the results for short prefixes in memcached (per language). The actual result shown to the user is around ten entries long, so cache entries would be small. (we could be "randomized put" to approximate LRU behavior).

Note that slow queries may time out. In such a case, we should cache an empty result set, to avoid issuing the same expensive/slow query again.

When T86530 is implemented this task is obsolete.

Event Timeline

daniel raised the priority of this task from to Needs Triage.
daniel updated the task description. (Show Details)
daniel changed Security from none to None.
daniel triaged this task as High priority.Dec 10 2014, 4:44 PM

Change 179914 had a related patch set uploaded (by Daniel Kinzler):
Cache type ahead results for short prefixes.

https://gerrit.wikimedia.org/r/179914

Patch-For-Review

daniel renamed this task from Cache responses for label prefix searches for short prefixes. to Cache wbsearchentities responses for for short prefixes..Dec 15 2014, 2:23 PM
Lydia_Pintscher renamed this task from Cache wbsearchentities responses for for short prefixes. to Cache wbsearchentities responses for short prefixes.Dec 15 2014, 2:50 PM
Jonas renamed this task from Cache wbsearchentities responses for short prefixes to [Task] Cache wbsearchentities responses for short prefixes.Sep 10 2015, 7:38 PM

Change 179914 abandoned by Daniel Kinzler:
Cache type ahead results for short prefixes.

Reason:
Jan suggested that it would make more sense to have the responses cached in varnish. We'd just have to send the corresponding http headers.

https://gerrit.wikimedia.org/r/179914

This comment was removed by daniel.

No idea if this would actually work. Need to check if our varnishes are configured to respect the cache headers on api requests. Need to check if the browser usually keeps the connection open for long enough. Need to check if varnish keeps the connection open when the browser closes it.

Closing as this ticket mainly focuses on the wikidata usecase, which now uses elastic search.

More than happy to happy to have something else opened for other reasons etc, but this one doesnt need to happen now for the reasons described in the ticket.