Page MenuHomePhabricator

Investigating caching issues (frontend)
Open, Needs TriagePublicBUG REPORT

Assigned To
None
Authored By
Soda
Jun 5 2023, 3:30 PM
Referenced Files
F37098148: pagejump-5.png
Jun 8 2023, 2:45 PM
F37098146: pagejump-4.png
Jun 8 2023, 2:45 PM
F37098147: pagejump-3.png
Jun 8 2023, 2:45 PM
F37098149: pagejump-2.png
Jun 8 2023, 2:45 PM
F37098150: pagejump-1.png
Jun 8 2023, 2:45 PM
F37097113: untitled.mp4
Jun 7 2023, 6:41 PM

Description

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.

Event Timeline

@Xover Can you send some details about a specific case where you see this (preferably including browser versions if possible).

Also if you are familiar with DevTools, could you generate a har of the requests of a specific session where you observe this behaviour

@Xover Can you send some details about a specific case where you see this (preferably including browser versions if possible).

My daily driver is most recent Safari on macOS.

I typically see this when opening multiple Page:-namespace pages in tabs. When switching to a tab the static page image is usually loaded (barring Thumbor slowness) because it's included in the HTML, but then OpenSeaDragon kicks in and replaces the image element while it loads the full-resolution thumb from JavaScript. This typically takes anything from "noticeable" to "ages" to do, so it certainly isn't pulling from the browser cache and doesn't seem likely to be a pre-rendered thumb from Thumbor.

You could probably lessen the impact of this by making the OSD image load async (don't overwrite the image element until the new thumb has finished loading). But better if it could load it from browser cache of course.

@Xover, just checking: do you have the high-res image function in "jump to file" turned on?

@Xover, just checking: do you have the high-res image function in "jump to file" turned on?

Now I'm afraid to check, because that would leave me with a rather spectacular amount of egg on my face, wouldn't it? 😝

@Xover, just checking: do you have the high-res image function in "jump to file" turned on?

Ah that would explain some of the weird caching behaviour. Also, I assume you are visiting the pages out of order ? (i.e. not sequentially one after another) [Asking this since our current caching strategy works best when sequentially viewing pages one after the other, the previous page preloads the next page etc]

@Xover, just checking: do you have the high-res image function in "jump to file" turned on?

Nope. JSON.parse(mw.user.options.get("userjs-JumpToFile")).loadHighres is false.

@Xover, just checking: do you have the high-res image function in "jump to file" turned on?

Nope. JSON.parse(mw.user.options.get("userjs-JumpToFile")).loadHighres is false.

@Xover Is this similar to the experience that you have ? Or do you see two specific image loads after the blue background of the Wikieditor appears ?

Is this similar to the experience that you have ? Or do you see two specific image loads after the blue background of the Wikieditor appears ?

That looks similar. To illustrate specifically:

Multiple Page: pages loaded in tabs:

pagejump-1.png (1×2 px, 1 MB)

Tab preview shows page image has loaded:

pagejump-2.png (1×2 px, 1 MB)

Switching to the tab shows the page image for a very brief moment:

pagejump-3.png (1×2 px, 807 KB)

Then it is replaced by the blue background when the PRP chrome loads:

pagejump-4.png (1×2 px, 379 KB)

Eight seconds later the new page image shows up:

pagejump-5.png (1×2 px, 865 KB)

I'm having trouble capturing this in a sensible way since Safari's Web Inspector is per-tab, but the above screenshots show roughly what's visibly happening. When switching to the tab the image has loaded, but without the PRP chrome, and then immediately (a matter of milliseconds, but enough to see it) disappears as the PRP chrome loads. This is presumably because Safari throttles JS in background tabs, but the second I make it active it starts running the event loop. At that point it sits waiting for the new page image for, in this case, 8 seconds or so. When Commons is slow it is, of course, longer. i.e. we're definitely waiting for Thumbor to generate a new thumb and fetching it over the network.

I can't get a full trace on this, but just looking at the resources loaded it has downloaded two thumbs: 1536px and 2048px versions of the current page (/1), and no version of the next page (/2). Neither page image is cached (this holds for subsequent pages too, I had 5+ in sequence open in tabs).

However, when I navigate to a page (/539) directly (in the same tab) the Web Inspector shows it loads three thumbs: 1535px and 2047px versions of the current page (/539) and a 1024px version of the next page (/540). When I navigate to the next page (/540) it loads 1536px and 2048px versions of that page (/540), and a 1024px version of the following page (/541). Every single image is loaded over the network. Note also the off-by-one pixel sizes of the two first thumbs here. In any case, it only preloads a 1024px version of the next page, so any other resolution thumb will always need to be generated and fetched over the network.

Oooh, here's a thought. If you're on a Mac, you probably have a retina screen and then you're using one of the 1.5x or 2x srcset URLs (1536, 2048), but sounds like only the 1x is pre-fetched.

Confirmed. 1024px is pre-fetched from looking at the previous page in the "Page" namespace. It does preload 1024px even if you use an higher resolution. Making it dynamic/calculated from the users resolution would fix the issue.

It would be nice to fetch the first page thumbnail up on visiting the Index page, using the same method as with the "Page" namespace. The "Page" namespace preloads 1024px for the previous and next page. That way, an user can upload PDF/DjVu, create an index and the first page is ready when the user saves the index.

Confirmed. 1024px is pre-fetched from looking at the previous page in the "Page" namespace. It does preload 1024px even if you use an higher resolution. Making it dynamic/calculated would fix the issue.

I mean yes that is definitely the correct solution for this problem, unfortunately, I don't/didn't see a way to deterministically figure out on the server-side a) what image size will be loaded due the srcset images b) what image will get loaded by Openseadragon.

EIS solves this by just forcibly loading/caching all possible size of the image, I wonder if we should do this any-way for the normal interface ?