Page MenuHomePhabricator

Improve performance of personalized recommendation API (morelike)
Closed, DeclinedPublic

Description

There are a couple of things we could look at for this, but we should definitely consider per-computation.

This will be even more important if we make the recommendations take into account more of your history, since that increases the amount of work that has to be done.

A simple approach to consider for a first pass is starting an asynchronous job (so it doesn't block saving the edit, which already takes too long) every time a page in the main namespace is saved by a logged in user (more maybe every X edits for a given user). This would basically do the same work, but then put the top n (9 for now, since that is the max the GUI uses) in a Redis list.

To avoid staleness, we could also do a recomputation whenever the user's rights change (to partially handle protection). Doing a recomputation of all users when protection of a page changes is probably not worth it, so we could either just tolerate those occasional issues (and recommend the page anyway), or keep that pass in the view-time filter (and sometimes show the user 7-8 recommendations or whatever).


Trello card: noOrfoPd

  • column: Bucket o' Mess

Event Timeline

Mass-declining tasks that only have the now defunct Growth-Team associated but no other projects, as announced in https://phabricator.wikimedia.org/T127072 - Feel free to reopen this task if it is still valid by associating an active project and resetting its status.

Jdforrester-WMF set Security to None.
Aklapper removed a subscriber: Mattflaschen-WMF.

MediaWiki-extensions-GettingStarted has been removed from Wikimedia wikis and is getting archived per T292654. Thus declining this task to reflect reality.

See e.g. GrowthExperiments-NewcomerTasks or #GuidedTour instead nowadays for related use cases.