Page MenuHomePhabricator

Performance review of Extension:ImageSuggestions
Closed, ResolvedPublic

Description

Description

Extension:ImageSuggestions is an extension that will send/display notifications to users when there is a likely suitable image for an unillustrated article on their watchlist.
It's essentially consists out of 3 parts:

  1. Data pipelines feed matches (article & relevant images) into HDFS/Cassandra
  2. A (weekly) maintenance script queries Cassandra and creates notifications for those matches (only 1 user/image per unillustrated watched article)
  3. Echo notification config, to display these notifications etc.

#1 & #2 are async processes; only #3 really runs live on-wiki.

From a user's POV, all they will see is a notification (max. 2 per user per week) that informs them about an article & a potentially relevant image.

Preview environment

The notification will be deployed on beta, but we will not be able to reliably generate images like we will in production: the data pipelines don't capture data from beta (and there really isn't any relevant data on beta to work with anyway)
#1 and #2 can't really be tested there.
We can, however, do a dry-run of the maintenance script (which outputs what notifications will be created without creating them)
We will also manually generate some sample notifications on beta to test #3.

Which code to review

#2 & #3 will live in the Extension:ImageSuggestions repo: https://gerrit.wikimedia.org/g/mediawiki/extensions/ImageSuggestions. WIP patches: #2, #3
#1 is pyspark code running on the stats cluster: https://gitlab.wikimedia.org/repos/generated-data-platform/datapipelines/-/tree/T296814-image-suggestions/image-suggestions

Commits to deploy extension and schedule maintenance script have not yet been started.

Performance assessment
  • What work has been done to ensure the best possible performance of the feature?

Not too much; it's essentially just a standard Echo notification implementation, like many others.
The initial data gathering is done asynchronously on the stats cluster and shouldn't impact site performance.
The maintenance script will only runs once a week; there's a query with a couple of joins, but uses indexes. Will obviously do a dry-run of said script when run for the first time.

  • What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?

None

  • Are there potential optimisations that haven't been performed yet?

None

  • Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: performance-team@wikimedia.org.

None

Event Timeline

it's essentially just a standard Echo notification implementation, like many others.
The initial data gathering is done asynchronously on the stats cluster and shouldn't impact site performance.
The maintenance script will only runs once a week; there's a query with a couple of joins, but uses indexes. Will obviously do a dry-run of said script when run for the first time.

If this is the extent of the extension, then I believe it might be more useful for us to instead wait until after deployment and simply be available for questions here or by email, for any validation or help you might want in confirming that it's running smoothly without much chance of infrastructure impact.

Please check or confirm the following:

  • There is currently no need for frontend asset bundles (besides icons provided to Echo that Echo displays and ships using its standard and already-used-in-prod mechanisms).
  • There is currently no need for hooks that run during web requests. (Hooks that run during other jobs and/or other maintenance scripts are generally considered low-risk).
  • There is currently no need for new databases, tables, or columns on tier-1 database hosts (core s1-8, es, x1; wikitech:MariaDB). And no demand for inserts to existing such databases, other than the insertion of echo notifications.
  • There is currently no need for frequent running of new or existing jobqueue jobs (e.g. jobs for 10% of edits or more often).

If all these are true, I'd say we can skip this review. Otherwise, it's at least of interest to be aware of it prior to going live. Specific risks will depend on what is being built. I notice that the extension's code repository is currently still empty. Though if indeed this simple, then I have no concerns with seeing it written, tested, staged, deployed and turned on live by the end of the month. I appreciate the heads up in the form of this task nonetheless!

How many users might get notified in one run of the maintenance script? I doubt it would be a disk space issue, but we should make sure that the script throttles the Echo DB updates with batching and LBFactory::waitForReplication() calls.

  • There is currently no need for frontend asset bundles (besides icons provided to Echo that Echo displays and ships using its standard and already-used-in-prod mechanisms).

Correct

  • There is currently no need for hooks that run during web requests. (Hooks that run during other jobs and/or other maintenance scripts are generally considered low-risk).

Only onBeforeCreateEchoEvent, to configure the notification: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageSuggestions/+/778215/2/includes/Hooks.php#32

  • There is currently no need for new databases, tables, or columns on tier-1 database hosts (core s1-8, es, x1; wikitech:MariaDB). And no demand for inserts to existing such databases, other than the insertion of echo notifications.

Correct

  • There is currently no need for frequent running of new or existing jobqueue jobs (e.g. jobs for 10% of edits or more often).

Correct

I notice that the extension's code repository is currently still empty.

Indeed. There are only 2 WIP patches ATM: 778216 & 778215

How many users might get notified in one run of the maintenance script? I doubt it would be a disk space issue, but we should make sure that the script throttles the Echo DB updates with batching and LBFactory::waitForReplication() calls.

waitForReplication is already in place per batch of 100 notification: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageSuggestions/+/778216/3/maintenance/GenerateNotifications.php#138

There will be max. 1 users per unillustrated article.per run.
We're still working on defining exactly what an "unillustrated page" is exactly (depending on definitions currently floating around, we're looking at a maximum of ±49k-135k articles on ptwiki), and how many of those have a suitable enough image suggestion (threshold & resulting numbers still TBD)

@Krinkle given the above, can this ticket be closed? Thanks!

CBogen claimed this task.

Resolving based on the above -- please reopen if necessary.

Yes, that's fine! Thank you for asking.