Image links
A user was able to DoS our wiki (http://wiki.wikimedia.it) simply by pasting into a page the attached table with a few hundreds links to images hosted on Commons. The page took about 60 seconds to render; 0.4 seconds after transforming them into interwiki links to Commons.
Version: 1.18.x
Severity: normal
Attached:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T66056 [InstantCommons] Page with hundreds image links takes 60 seconds to parse | |||
| Open | None | T56033 Files/images should be fetched in batch by parser, not one at a time |
And the original revision, where they were actual image thumbs, takes 117.522 seconds.
In theory after the first time its rendered it should be faster if caching is enabled.
(In reply to Bawolff (Brian Wolff) from comment #2)
In theory after the first time its rendered it should be faster if caching
is enabled.
Well, I need the wiki and the page in question to be functional and editable so I can't test this theory. :)
What is the actual bug here: that parsing a page with hundreds of remote images is slow, or that this can be used to DOS the site? The first sounds like a "don't do that then" bug. The parser needs certain image attributes to generate the HTML code, MediaWiki needs to make an API call to Commons to get that information; the calls stack up when there are lots of images. It might be possible to batch them somehow, or render the page with placeholders, put the API calls in a job queue and reparse the page when they have finished; both look like complex changes for relatively little benefit.
As for the DOS part, maybe there could be a limit of remote links per page that the wiki operator can set?
(In reply to Tisza Gergő from comment #4)
What is the actual bug here: that parsing a page with hundreds of remote
images is slow, or that this can be used to DOS the site?
It depends on what devs prefer to fix first. :)
(In reply to Nemo from comment #6)
Andre, why did you change to 1.23-git? Did someone test this on 1.23?
This is not really a new issue. Pretty sure still present today, as well as for many years. Instant commons isnt the most optimized for performance, and even ignoring that, we have performance problems for non instant commons images if you add several hundred to a page
Nemo: This is really about 1.18.x? I thought you made a typo. :) I'm tempted to close as "please try with a recent and supported MediaWiki version" then...
Yes, that wiki runs on Debian so it's ancient stuff. :) I don't know where else to test but bawolff confirms this is probably true on 1.24alpha too. Oh well.
Yeah, bug 54033 is about the same issue; I vaguely propose a batch lookup there as a solution but have not implemented it yet. :)
Just FYI, I'm experimenting with performance improvements in the extension QuickInstantCommons. Initial tests show a 55x speed improvement, and I also have additional ideas that are not yet implemented.