Change Details

>>! In T337649#8901633, @Xover wrote: >>>! In T337649#8901152, @Soda wrote: >>The dual image load is being caused by a high dpi screen and overall should only hit the cache, since by the time all resources are loaded, the cache for Thumbor should already contain those specific images (in theory). > > This does not comport with my (anecdotal) experience. The full-resolution image XHR-loaded by Open SeaDragon is very rarely (never?) cached when requested, and takes up to 20 seconds to load. The user experience is: 1) open a Page:-namespace page, 2) wait for however long it takes for the basic thumb to load, 3) watch the just loaded thumb get blanked by OSD, 4) wait for OSD to load the full-size thumb, 5) start editing 20–45 seconds after opening the page. Exact timing depends on how fast/slow image loads are, but when it's as slow as it's been for a while now—and especially now that it's completely broken, the behaviour is really noticeable. But, of course, if the timings Joe reported in a comment above (eqiad: 9s, codfw: <1s) are representative then this is going to be invisible to users that end up hitting codfw.

>>! In T337649#8901633, @Xover wrote: >>>! In T337649#8901152, @Soda wrote: >>The dual image load is being caused by a high dpi screen and overall should only hit the cache, since by the time all resources are loaded, the cache for Thumbor should already contain those specific images (in theory). > > This does not comport with my (anecdotal) experience. The full-resolution image XHR-loaded by Open SeaDragon is very rarely (never?) cached when requested, and takes up to 20 seconds to load. The user experience is: 1) open a Page:-namespace page, 2) wait for however long it takes for the basic thumb to load, 3) watch the just loaded thumb get blanked by OSD, 4) wait for OSD to load the full-size thumb, 5) start editing 20–45 seconds after opening the page. Exact timing depends on how fast/slow image loads are, but when it's as slow as it's been for a while now—and especially now that it's completely broken, the behaviour is really noticeable. But, of course, if the timings Joe reported in a comment above (eqiad: 9s, codfw: <1s) are representative then this is going to be invisible to users that end up hitting codfw. Solution: In the "Page" namespace the previous and next page thumbnails are pre-loaded. This seems to be always 1024px. If it would be calculated/dynamic, it would solve the issue.

>>! In T337649#8901633, @Xover wrote: >>>! In T337649#8901152, @Soda wrote: >>The dual image load is being caused by a high dpi screen and overall should only hit the cache, since by the time all resources are loaded, the cache for Thumbor should already contain those specific images (in theory). > > This does not comport with my (anecdotal) experience. The full-resolution image XHR-loaded by Open SeaDragon is very rarely (never?) cached when requested, and takes up to 20 seconds to load. The user experience is: 1) open a Page:-namespace page, 2) wait for however long it takes for the basic thumb to load, 3) watch the just loaded thumb get blanked by OSD, 4) wait for OSD to load the full-size thumb, 5) start editing 20–45 seconds after opening the page. Exact timing depends on how fast/slow image loads are, but when it's as slow as it's been for a while now—and especially now that it's completely broken, the behaviour is really noticeable. But, of course, if the timings Joe reported in a comment above (eqiad: 9s, codfw: <1s) are representative then this is going to be invisible to users that end up hitting codfw. Solution: In the "Page" namespace the previous and next page thumbnails are pre-loaded. This seems to be always 1024px. If it would be calculated/dynamic, it would solve the issue.