#### Description
In fiscal Q4 2019-2020 the Product Infrastructure team plans to build the basic infrastructure for push notifications for the Wikimedia product platforms (iOS, Android, and web)The goal of the project is to use push technology to provide MediaWiki notifications to Wikimedia web and app users. The initial focus of the project will beis on providing push notifications for the apps.
The scope of work will tentativelypush notification system consists of the following:wo components:
# A new Echo notifier type to direct Echo events to be handled via push notification.
# A new PushNotifications MW extension to manage push notification subscriptions, receive notification requests, and submit job queue jobs to make requests to push vendor APIs- Push subscription management and notification request support in the [[ https://www.mediawiki.org/wiki/Extension:Echo | Echo ]] extension; and
# Creation of a new Change Propagation processing unit to handle job queue push notification request job- A standalone service ([[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications/ | push-notifications ]]) for batching requests for submission to third party push providers.
We would appreciate performance review support for #2 and (maybe) #3.In the initial (apps-only) implementation, to mitigate the user privacy and security risks associated with sending potentially sensitive information to users via third-party systems, pushed messages will contain only a short descriptor (e.g., `checkEchoV1`) to prompt the apps to retrieve message content from Wikimedia servers (e.g., by request to the Action API's [[ https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bnotifications | notifications ]] module). Further, I don't believe that #1 will have any performance implications in itselfthe push-notifications service will collect push notification requests and send them in periodic batches in order to increase the difficulty of drawing inferences between on-wiki actions and messages traversing the public internet.
TechCom RFC: {T249065}
#### Preview environment
//(Insert one or more links to where the feature can be tested, e.g. on Beta Cluster.)//Target deployment date: TBD
Hosting the changes on Beta Cluster is a requirement prior to performance review. Please ensure that the feature can be used directly on the link(s) provided, without any data entry such as having to create an article. Any sample content needed should already be present.#### Preview environment
IfThis code is deployed to the changes cannot be hosted onBeta Cluster. The push-specific additions to Echo are live on all Beta Cluster wikis, explain why and provide links to an alternate public environment instead where the Performance Team can also SSH into. Links to code only is insufficient for a performance reviewand the extension is configured to send push notification requests to the push-notifications service instance running on [[ https://openstack-browser.toolforge.org/server/deployment-push-notifications01.deployment-prep.eqiad.wmflabs | deployment-push-notifications01 ]].
#### Which code to review
//(Provide links to all proposed changes and/or repositories. It should also describe changes which have not yet been merged or deployed but are planned prior to deployment. E.g. production Puppet, wmf config, or in-flight features expected to complete prior to launch date, etc.).//* https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications (entire repo)
* https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Echo
** Relevant files/directories:
*** db_patches/echo_push_provider.sql
*** db_patches/echo_push_subscription.sql
*** includes/api/Push/*
*** includes/Push/*
*** includes/EchoHooks.php (see onApiMainModuleManager())
*** includes/EchoServices.php
*** tests/phpunit/api/Push/*
*** tests/phpunit/integration/**/*
*** tests/phpunit/unit/Push/*
*** ServiceWiring.php
#### Performance assessment
Please initiate the performance assessment by answering the below:
- What work has been done to ensure the best possible performance of the feature?//What work has been done to ensure the best possible performance of the feature?//
I would expect this feature to have little to no performance impact on the sites.
With these changes to Echo, if a site is configured to add a push notifier type, when an Echo event occurs, the push notifier's handler function determines whether the user to be notified has elected to be notified about events of that type by push, and if so, enqueues a job to asynchronously retrieve the user's stored push subscriptions and make a request to the push service. An index has been added to the push subscriptions table (echo_push_subscription) to ensure fast lookups of push subscriptions by a user's central ID.
The push service itself should have no impact on the performance of the sites.
- //What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?//
A primary reason for having a standalone service for forwarding push notification requests on to the push platform gateways, as opposed to a lighter-weight solution such as ChangeProp rules, is to implement custom batching behavior recommended during privacy review to help mitigate risks to user privacy. In brief, the goal is to add entropy to the system to make it more difficult for an attacker to infer connections between actions on-wiki and notifications sent to a particular device. These recommendations include sending requests on to push provider gateways in batches; introducing randomzied delays before batched request submission; and sending no-op requests to add additional noise.
As such, the service is essentially intended to slow down requests. A key question (and a potential weak point) is how the service will perform under load.
- //Are there potential optimisations that haven't been performed yet?//
A more aggressive optimization on the MediaWiki side would be to have the push notifier handler function immediately enqueue a job for each Echo event without doing any check for whether push notifications apply to the user and event type; that would instead be checked at the time the job is performed. This would likely eliminate any possibility of a direct performance impact arising from the feature, but at the cost of sharply increasing the number of jobs enqueued (which might have an indirect performance impact).
- 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: [[ mailto:performance-team@wikimedia.org | performance-team@wikimedia.org ]].
No measurements are yet in place. We would appreciate guidance on what measurements are needed in this case, if any.