Description
(Please provide the context of the performance review, and describe how the feature or service works at a high level technically and from a user point of view, or link to documentation describing that.)
The WikimediaCampaignEvents extension adds WMF-specific features to the CampaignEvents extension. Currently, it provides a single such feature: it lets organisers organizers share the grant ID (if they have one) when they configure a specific event so that grant officers can easily track and analyze the impact of events supported by grants.
Here's a high-level overview of how it works:
- When the organiser visits Special:EnableEventRegistration (or Special:EditEventRegistration), they see a form field where they can enter the grant ID
- If they enter an ID and submit the form, then we run the following validations on the grant ID value:
- First check if it's empty, in which case we skip straight to (3.)
- Then check if it's the same value as currently stored in the database, and skip to (4.) if it is.
- Then check if the format of the ID is correct (e.g., 1234-56789). If not, show an error.
- If the format is valid, make a request to the Fluxx API to confirm that the ID exists and is valid. If not, show an error.
- If the ID is valid, we store it into the database. Or we just delete it from the DB if the value is empty.
- Event organizers can then see their grant ID in two places: in Special:EditEventRegistration (where they can remove/update it if they wish), and in Special:EventDetails (read-only).
Preview environment
(Insert one or more links to where the feature can be tested, e.g. on Beta Cluster.)
TODO: we will provide a link to the beta cluster as soon as the extension is enabled there.
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/g/mediawiki/extensions/WikimediaCampaignEvents
NOTE: There's more planned work to do, and the code base is not ready for review at this time.
Performance assessment
Please initiate the performance assessment by answering the below:
- What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?
Making requests to the Fluxx API is probably the main/only bottleneck in the application. In particular, given that these requests must be authenticated, we need to request an authorization token before we can send the actual request, which would mean 2 HTTP requests when the form is submitted.
- What work has been done to ensure the best possible performance of the feature?
The optimisations we implemented are all geared towards avoiding HTTP requests if possible. The first barrier is a simple validation layer to ensure that the grant ID value is non-empty, different than the one we already have, and that it matches a certain pattern. Validation with Fluxx is only attempted if the grant ID looks legitimate.
Next, we use object caching to reduce the number of HTTP request. The Fluxx token is cached in APCu for as long as possible (the API includes an expires_in field). API responses for an individual grant ID are also cached in APCu for 30 seconds.
We believe that changes to the grant ID would be relatively uncommon in real-world usage, and therefore that the cache may not be extremely effective, particularly the one for individual IDs. The main goal of this cache is to optimise subsequent form submissions whenever an unrelated validation error occurs, so that 1) we do not attempt validation of a grant ID we just validated, and 2) we don't need to re-authenticate if the user tries a different ID. Still, we would probably be making 2 requests most of the times in the happy path.
- Are there potential optimisations that haven't been performed yet?
The aforementioned caching could be improved further. For instance, we might consider switching to a shared cache backend such as memcached. We could also consider increasing the cache TTL for individual IDs. And finally, we could cache request failures caused by the ID being invalid (as opposed to other issues such as network errors, or bad auth data, etc.); however, this is not straightforward as we would need to further distinguish between the possible failure scenarios.
- 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 MediaWiki Platform Team for advice: mediawiki-platform-team@wikimedia.org.
We currently have no performance measurements in place.