Page MenuHomePhabricator

[InstantCommons] Page with hundreds image links takes 60 seconds to parse
Open, NormalPublic

Description

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:

Details

Reference
bz64056

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 3:14 AM
bzimport set Reference to bz64056.
bzimport added a subscriber: Unknown Object (MLST).
Nemo_bis created this task.Apr 17 2014, 2:07 PM

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. :)

Tgr added a comment.Apr 17 2014, 7:37 PM

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. :)

Andre, why did you change to 1.23-git? Did someone test this on 1.23?

(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.

Tgr added a comment.May 9 2014, 11:46 PM

Probably caused by / could be fixed by bug 54033.

brion added a comment.May 9 2014, 11:49 PM

Yeah, bug 54033 is about the same issue; I vaguely propose a batch lookup there as a solution but have not implemented it yet. :)

Masao added a subscriber: Masao.Mar 23 2015, 6:59 AM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:36 PM
Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptSep 4 2015, 6:36 PM
Restricted Application added a project: Commons. · View Herald TranscriptJan 27 2017, 10:11 PM