Last modified: 2014-05-15 06:07:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T66056, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 64056 - [InstantCommons] Page with hundreds image links takes 60 seconds to parse
[InstantCommons] Page with hundreds image links takes 60 seconds to parse
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 54033
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-17 14:07 UTC by Nemo
Modified: 2014-05-15 06:07 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Image links (19.51 KB, text/plain)
2014-04-17 14:07 UTC, Nemo
Details

Description Nemo 2014-04-17 14:07:00 UTC
Created attachment 15129 [details]
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.
Comment 1 Nemo 2014-04-17 14:08:10 UTC
And the original revision, where they were actual image thumbs, takes 117.522 seconds.
Comment 2 Bawolff (Brian Wolff) 2014-04-17 16:16:21 UTC
In theory after the first time its rendered it should be faster if caching is enabled.
Comment 3 Nemo 2014-04-17 16:19:35 UTC
(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. :)
Comment 4 Tisza Gergő 2014-04-17 19:37:40 UTC
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?
Comment 5 Nemo 2014-04-17 19:41:46 UTC
(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. :)
Comment 6 Nemo 2014-04-22 08:59:22 UTC
Andre, why did you change to 1.23-git? Did someone test this on 1.23?
Comment 7 Bawolff (Brian Wolff) 2014-04-22 14:41:05 UTC
(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
Comment 8 Andre Klapper 2014-04-22 15:36:45 UTC
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...
Comment 9 Nemo 2014-04-22 15:48:53 UTC
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.
Comment 10 Tisza Gergő 2014-05-09 23:46:26 UTC
Probably caused by / could be fixed by bug 54033.
Comment 11 Brion Vibber 2014-05-09 23:49:00 UTC
Yeah, bug 54033 is about the same issue; I vaguely propose a batch lookup there as a solution but have not implemented it yet. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links