I was only able to reproduce this with a very complex/large file. Thumbs for smaller files seen to show up almost instantaneously, but https://commons.wikimedia.beta.wmflabs.org/wiki/File:Colosseum_final.stl takes ~18 seconds to generate a thumb.
When loading the file page fast enough after upload, the thumb fails to load (the thumbnailing job responds with a 429 - rate limited, AFAIU)

@Gilles: I assume thumbs will generate a lot faster in production than on our beta infra; but do you think there's something we need to do here?

• Should we limit the size of files to be uploaded? (preferably not)
• Should we attempt to optimize STL thumbnailing (e.g. remove shadows - probably not too much to be gained, from some quick tests)
• Or should we be ok performance-wise?

Judging from T166699: Evaluate performance of 3d2png on beta cluster, we probably should be ok, but I'm trying to get a feel for the odds of thumbnails taking long enough to generate that they don't show up at first.
We could maybe have some script detect when/if a thumb fails to load, maybe check how recent the upload was, and do something useful with that info (show some message; re-attempt fetching thumb after a few seconds, ...)?
Or would that be overkill and will it all be fine and fast enough in prod?

Files that can be expensive to thumbnail are nothing new, giant images and multipage documents also fall in that category. It's not uncommon in production for giant TIFFs to take 20 seconds to render.

If slowness of thumbnail generation becomes a significant problem in production for 3D, the most obvious optimization in this case would be to order servers with GPUs, which would vastly accelerate the rendering of 3D thumbnails, probably making something like the example you gave render in milliseconds.

Audiences is currently in the process of asking for GPU servers to perform OpenCV feature recognition (ask @Fjalapeno about it), there could be a colocation opportunity there. I expect the volume of 3D thumbnail generation to be fairly low, ordering new servers just for this task seems like a bit of an extravagant budget expenditure, which is why I think it would make more sense to piggy-back on something else.

In terms of software, I don't really see how we could make this cheaper, it's pretty basic 3D rendering. I doubt that casting shadows with 2 lights sources makes a big difference.

As for 429s, there are different types of rate limits, it could just be that you triggered the per-IP limit by personally triggering the rendering of many new thumbs in a short period of time, or the per-file limit by refreshing the same file while it was trying to render, etc. Again, I don't think this is any different than expensive files in production and the rate of 429s shouldn't be worse than with other expensive thumbnail types. Note that there is a rate limit specifically for expensive files, so just like PDFs, STL files are more sensitive to that than say, JPGs. Precisely to avoid expensive files being too disruptive for all the other thumbnail requests happening.

I don't see anything worth worrying about at this point. People uploading a lot of 3D files will probably trip some 429 limits, but that's no different than people uploading a lot of large PDFs. Users who deal with heavy files are used to that and the thumbnails always end up fixing themselves later. If 3D thumbnail generation time is the source of a lot of complaints, then request GPU-accelerated hardware for a separate small Thumbor cluster dedicated to 3D rendering.

@Ramsey: Is this good enough for you? It could happen that a thumbnail is not yet ready, but that is already the case for certain other large files/types as well.
Do we want to look into ordering more GPU capacity, work on something to indicate that the thumb is not ready (it it fails to load shortly after upload), and/or just wait it out until we know whether it's an issue worth addressing?

Normally I'd be a little more easy going about it, but since this launch has a fair degree of hype around it, I think we need to do as much polish as we can.

I wouldn't go so far as saying we need more GPU capacity yet. We still might, but I think we need to see how things do in the production environment first.

My preferred "quick fix" would just be to have some kind of indicator/placeholder, like I mentioned in the original ticket description. But if that would take more than a couple of days to implement, I might reconsider :)

Change 404614 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/3D@master] Display placeholder text until 3D thumb is loaded

https://gerrit.wikimedia.org/r/404614

Change 404614 merged by jenkins-bot:
[mediawiki/extensions/3D@master] Display placeholder text until 3D thumb is loaded

https://gerrit.wikimedia.org/r/404614