Change Details

(TODO: task is currently to unstub this ticket. subscribe #performance-team when ready) #### Description **Problem we are solving**: The WMDE Technical Wishes [[ https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes | team ]] is working on maps improvements, and our current goal is to serve historical versions of annotated maps. The system can currently show only the latest revision of these maps. The lack of versioned maps is especially problematic on wikis such as German Wikipedia, which use FlaggedRevs page stabilization. Kartographer mapframe rendering is currently disabled on these wikis, otherwise the stabilized pages would often include blank maps (since the latest version doesn't match page contents). **Planned implementation**: Each hop in the pipeline for retrieving maps will support a `revid` parameter. With this, it will become possible to render any historical version of a map. One major performance consideration has been that map-containing pages will be edited much more often than the mapframes themselves. To mitigate this, we're proposing that the varnish cache in front of rendered maps strip "revid" from the string used to compute the internal hash key. This works because a hash of the mapframe content is already included in the URL parameters, and will still be included in the hash key. This way, maps are only re-rendered when the mapframe contents change. **Example**: Example map with annotations: [[ https://maps.wikimedia.org/img/osm-intl,6,53.383333,-1.466667,300x400.png?lang=en&domain=en.wikipedia.org&title=Downton+Abbey&groups=_39680418b083bf0edb91278ce24d9075eb0496fa | here ]] #### Preview environment TODO: //(Insert one or more links to where the feature can be tested, e.g. on Beta Cluster.)// 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. If the changes cannot be hosted on Beta Cluster, 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 review. #### 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.).// #### 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 are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? - Are there potential optimisations that haven't been performed yet? - 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 ]].

(TODO: task is currently to unstub this ticket. subscribe #performance-team when ready) #### Description **Problem we are solving**: The WMDE Technical Wishes [[ https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes | team ]] is working on maps improvements, and our current goal is to serve historical versions of annotated maps. The system can currently show only the latest revision of these maps. The lack of versioned maps is especially problematic on wikis such as German Wikipedia, which use FlaggedRevs page stabilization. Kartographer mapframe rendering is currently disabled on these wikis, otherwise the stabilized pages would often include blank maps (since the latest version doesn't match page contents). **Planned implementation**: Each hop in the pipeline for retrieving maps will support a `revid` parameter. With this, it will become possible to render any historical version of a map. One major performance consideration has been that map-containing pages will be edited much more often than the mapframes themselves. To mitigate this, we're proposing that the varnish cache in front of rendered maps strip "revid" from the string used to compute the internal hash key. This works because a hash of the mapframe content is already included in the URL parameters, and will still be included in the hash key. This way, maps are only re-rendered when the mapframe contents change. **Example**: Example map with annotations: [[ https://maps.wikimedia.org/img/osm-intl,6,53.383333,-1.466667,300x400.png?lang=en&domain=en.wikipedia.org&title=Downton+Abbey&groups=_39680418b083bf0edb91278ce24d9075eb0496fa | here ]] #### Preview environment TODO: //(Insert one or more links to where the feature can be tested, e.g. on Beta Cluster.)// 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. If the changes cannot be hosted on Beta Cluster, 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 review. #### 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://github.com/wikimedia/mediawiki-extensions-Kartographer/commit/373d0f0540badec056406df79f5aab894e6560d1 * Kartographer's mapdata API can look up maps from old revisions of an article. * TODO... #### 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 are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? - Are there potential optimisations that haven't been performed yet? - 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 ]].

(TODO: task is currently to unstub this ticket. subscribe #performance-team when ready) #### Description **Problem we are solving**: The WMDE Technical Wishes [[ https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes | team ]] is working on maps improvements, and our current goal is to serve historical versions of annotated maps. The system can currently show only the latest revision of these maps. The lack of versioned maps is especially problematic on wikis such as German Wikipedia, which use FlaggedRevs page stabilization. Kartographer mapframe rendering is currently disabled on these wikis, otherwise the stabilized pages would often include blank maps (since the latest version doesn't match page contents). **Planned implementation**: Each hop in the pipeline for retrieving maps will support a `revid` parameter. With this, it will become possible to render any historical version of a map. One major performance consideration has been that map-containing pages will be edited much more often than the mapframes themselves. To mitigate this, we're proposing that the varnish cache in front of rendered maps strip "revid" from the string used to compute the internal hash key. This works because a hash of the mapframe content is already included in the URL parameters, and will still be included in the hash key. This way, maps are only re-rendered when the mapframe contents change. **Example**: Example map with annotations: [[ https://maps.wikimedia.org/img/osm-intl,6,53.383333,-1.466667,300x400.png?lang=en&domain=en.wikipedia.org&title=Downton+Abbey&groups=_39680418b083bf0edb91278ce24d9075eb0496fa | here ]] #### Preview environment TODO: //(Insert one or more links to where the feature can be tested, e.g. on Beta Cluster.)// 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. If the changes cannot be hosted on Beta Cluster, 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 review. #### 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://github.com/wikimedia/mediawiki-extensions-Kartographer/commit/373d0f0540badec056406df79f5aab894e6560d1 * Kartographer's mapdata API can look up maps from old revisions of an article. * TODO... #### 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 are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? - Are there potential optimisations that haven't been performed yet? - 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 ]].