Change Details

Issue: geopoints loading takes long for complex sparql queries Example: https://en.wikipedia.beta.wmflabs.org/wiki/Maptests/Geopoints_by_SPARQL Investigate [] Why does it take so long to load? * One issue is that the beta cluster causes other delays when saving or viewing a page, so it's hard to see how the new feature affects timing. * Parser debugging reports that 10s of real time are spent parsing. This is much lower than the expected timeouts... [ ] How will slow queries interact with geoshape expansion enabled by T323113? [x] Evaluate possible solutions and identify the pro/cons of each direction, including what other problems could be solved in addition Possible solutions 1. Cache the results of SPARQL requests in a local database for a day or so. SPARQL should take care of it’s own result caching and does already, but it doesn’t 2. Cache the final GeoJSON results in a local database for a day or so. 3. Do the query only on page parsing see {T322353} - Has the advantage that purging is a solved concept - Potential issue: page rendering (also preview) will take a long time, during which the page is blank and even text is unavailable. - Page rendering in steps (not available yet, but discussed, see T282585) - Parser already has a fall back to go for a stale version when loading is too long - Most pages won't have very complex, slow queries. - If expansion fails, fall back to the previous behavior and leave it to the client to expand external data.

Issue: geopoints loading takes long for complex sparql queries Example: https://en.wikipedia.beta.wmflabs.org/wiki/Maptests/Geopoints_by_SPARQL Investigate [] Why does it take so long to load? * One issue is that the beta cluster causes other delays when saving or viewing a page, so it's hard to see how the new feature affects timing. * Parser debugging reports that 10s of real time are spent parsing. This is much lower than the expected timeouts... [ ] How will slow queries interact with geoshape expansion enabled by T323113? [x] Evaluate possible solutions and identify the pro/cons of each direction, including what other problems could be solved in addition Alternatives considered 1. ~~Cache the results of SPARQL requests in a local database for a day or so. SPARQL should take care of it’s own result caching and does already, but it doesn’t~~ 2. ~~Cache the final GeoJSON results in a local database for a day or so.~~ 3. Do the query only on page parsing - Implemented as {T322353}. - Has the advantage that purging is a solved concept - Potential issue: page rendering (also preview) will take a long time, during which the page is blank and even text is unavailable. - Page rendering in steps (not available yet, but discussed, see T282585) - Parser already has a fall back to go for a stale version when loading is too long - Most pages won't have very complex, slow queries. - If expansion fails, fall back to the previous behavior and leave it to the client to expand external data.

Issue: geopoints loading takes long for complex sparql queries Example: https://en.wikipedia.beta.wmflabs.org/wiki/Maptests/Geopoints_by_SPARQL Investigate [] Why does it take so long to load? * One issue is that the beta cluster causes other delays when saving or viewing a page, so it's hard to see how the new feature affects timing. * Parser debugging reports that 10s of real time are spent parsing. This is much lower than the expected timeouts... [ ] How will slow queries interact with geoshape expansion enabled by T323113? [x] Evaluate possible solutions and identify the pro/cons of each direction, including what other problems could be solved in addition Possible solutionsAlternatives considered 1. ~~Cache the results of SPARQL requests in a local database for a day or so. SPARQL should take care of it’s own result caching and does already, but it doesn’t~~ 2. ~~Cache the final GeoJSON results in a local database for a day or so.~~ 3. Do the query only on page parsing see - Implemented as {T322353}. - Has the advantage that purging is a solved concept - Potential issue: page rendering (also preview) will take a long time, during which the page is blank and even text is unavailable. - Page rendering in steps (not available yet, but discussed, see T282585) - Parser already has a fall back to go for a stale version when loading is too long - Most pages won't have very complex, slow queries. - If expansion fails, fall back to the previous behavior and leave it to the client to expand external data.